To state the obvious: “AI” is all the rage nowadays, and for good reason. We are probably experiencing the next major technological breakthrough in real-time and this should be an exciting journey.
As Product Managers and leaders, we obviously have a lot of questions. On the one hand, we worry about how this will affect our jobs. On the other hand, we are left (if not expected) to figure out how to make AI part of our products.
Before attempting to answer these questions, we should first get a few things straight, however.
When we say “AI”, we tend to refer to recent innovations around large language models (LLMs) such as OpenAI’s ChatGPT and Google Bard. This form of AI, which is also referred to as “generative AI” is made available by external providers who have spent years and lots of data to train these models. Those models run on their own (cloud) infrastructure and can be accessed by APIs these providers have made available. The output is largely text- (and recently also image and video-) based. The term “AI” in general is a much larger set of technologies and approaches, not just generative AI.
Then there is “Machine Learning” (ML), which is technically a subset of AI. ML has been around for years and has already found many useful applications which have made inroads into our day-to-day lives, oftentimes without much fanfare (Amazon recommendations, anyone?). ML tends to be more focused in its application compared to generative AI and is great at dealing with numerical and quantitative data. Unlike the big LLMs, companies can create, train, and run their ML models on their own infrastructure with their own proprietary data. With that, there are much fewer external dependencies.
Getting back to how “AI” impacts Product Managers, there are really several parts to this answer: Continue reading
As “product people”, we own and nurture software products with the goal of creating value for our customers (users) and achieving business results for the organizations we’re part of.
We need a way to articulate how well-developed (or nascent) the different parts of our application are, make decisions on where to invest time and effort, and layout a roadmap showing the progression of our app. (And once in a while we also need a way to peek at and compare ourselves to the competition). In this post, I’ll suggest a tool to help with these concerns—the concept of “feature set maturity”. Continue reading this post on Mind The Product
How to Select Team Members that contribute to a Healthy Team Culture
Software is eating the world,” they say and it’s certainly true. But I’d argue that teams are eating the world as well. (Maybe it’s not a coincidence that basically all modern software is created by teams.) Gone are the days when it was all about individual contribution and achievement. Nowadays, many organizations have realized that while the individual employee is important, hardly any significant contribution comes from individuals alone, but from high-performing teams. It’s the team that’s unlocking and amplifying the potential of its members to the point where… continue reading
Twelve Things I Learned Working in an Office Again After Two Years Remote
It’s happened: After over two years of working remotely and learning how to make remote teams successful, I took a new job and I’m back “in the office”. I traded my well-equipped home office with all of its privacy and the benefits of personal surroundings for a desk in an open office at a growing local startup, which is fortunately only three miles from my house.
I was expecting this transition to be quite an adjustment and while it was in some ways, old muscle memory set in and I quickly settled into the new routine. However, there are quite a few things I learned along the way: continue reading
As product managers, some — or maybe even many — of us have been able to escape the Build Trap and evolve past the Feature Factory. Hopefully behind us are the days of chasing purely feature-based roadmaps and instead, we’re working in empowered teams trying to achieve outcomes.
As part of this transition, we have started to use product analytics tools like Pendo to understand user behavior and sentiment from a quantitative perspective. As we’re confirming user problems to solve and evaluating various solutions, we’re conducting user interviews and usability tests, which means we’re amassing all kinds of qualitative information.
This introduces a set of new challenges: continue reading
Everyone loves a good metric. As product managers, we probably proudly proclaim that we are getting better at making decisions based on data rather than gut instinct. How everyone gathers, visualizes, and uses information — in product management and beyond — has certainly changed for the better over the years. In the past, we were overloaded with data and graphs to the point where we couldn’t see the forest through the trees anymore. But now, we have learned to become more selective. Now the few, hand-picked metrics we use should all be driving decisions and be highly actionable, right?
And of course, there’s anything wrong with that. However, … finish reading on ProductCraft
Have you ever wondered how import leaders (Product Owners, Scrum Masters, Tech Leads, and stakeholders) are when it comes to the health and productivity of Agile teams? Well, I looked at the data and here is what it says: Continue Reading
Distributed Agile teams may not be the norm, but they’re here to stay and their numbers are steadily growing. In my own experience, they can work pretty well and become quite productive (see my prior post), although there always seems to be a “remote penalty” compared to fully co-located teams, basically the inevitable cost and friction introduced by not being in the same place.
Is it possible to boost such a team’s performance further and reap benefits similar to co-located teams? Can you “virtually co-locate”?
A recent experiment has convinced me that the answer to these questions is “Yes”!
The Starting Point
I was working with a “regular”-sized Kanban team that had already worked together for a while and found its stride. Members were located from the US West Coast, the Mid West and Florida to South America with a maximum time difference of 4 hours. Things were going pretty well: We were conducting the typical Agile ceremonies via Zoom sessions, used Azure DevOps to manage work, collaborated via Slack, and had working sessions and meetings as needed.
The team had been working on a new module of a SaaS application and we were faced with the challenge of delivering the MVP within about 5 weeks, which was doable, but not easy. We discussed how to work together differently to intensify our efforts and increase our chances of delivering on time.
We had the option of traveling to a central location and work together in the same office for a few weeks, which obviously carried not insignificant costs such as travel time and expenses, logistical challenges including visas, and being away from our families. While we left that option on the table for later, the team decided to try out a different set of working agreements first. Continue reading