And slowing engineering down is certainly not the answer. | Photo by Jodi B Photography
I do not like myself for being the bottleneck now
I have always believed that product development teams should move quickly. Some might say extremely quickly. Customers do not benefit from functionality that takes months longer than it should to reach them. And there is no doubt that long development cycles make it harder to gauge customers' usage to find what works and how to improve it. This is one reason we at Aha! focus so intently on building the Minimum Lovable Product and work hard to keep the release dates we set once we have a sense of how long something will take. (It is also why we created an entire methodology to respond quickly to customers and colleagues.)
Today, AI is helping us build software faster than ever. And engineers are increasingly ready for the next feature before our product managers are ready to give it to them.
Faster engineering puts more pressure on product leaders to know where the product should go next.
Chris and I started talking about the shift last year when we came up with the Waters theory: our belief that the share of code AI writes will keep growing. At the time, we were mostly thinking about the implications for engineering. But we are now feeling the effects in product management, too. I assumed I would be ready if and when we got here. I was not, and I really do not like being the reason someone else has to wait.
Product managers everywhere are now trying to keep up.
You might assume that deciding what to build gets easier as engineering moves faster. I am finding the opposite. Ideas we might have ruled out a few years ago because they would take too long to build are now back in the conversation. I would much rather have too many good ideas than too few. But choosing wisely is still fundamental. Knowing what not to build is as important as knowing what to build.
And this is how I ended up as the bottleneck.
Knowing more than just what engineering should build next is key. You also need to understand why one task deserves to come before everything else.
I am certainly not going to ask engineering to slow down. So the adjustment needs to come from me and the rest of our product team. We need to be ready earlier, which means we need to be even closer to customers than we were. Here is what we are doing:
Set our product strategy every six months: We have followed this cadence at Aha! for years, but faster engineering means we can seriously consider more features within the same period. That makes it even more important to evaluate each one against the strategy before adding it to the roadmap.
Define the major epics that support your initiatives: We agree on these with the broader team and use them to lay out the major areas of work ahead. Our product managers can start thinking about those areas well before we get into the details.
Build prototype templates that match your product: This is a newer practice for us; our templates in Aha! Builder already include the navigation, layouts, and components we use throughout the product. When it is time to prototype a feature, our PMs start with one of these instead of recreating the basics every time.
Have AI continuously review customer feedback: We use Elle, the AI assistant in our software, to work through feedback and see connections across what customers are telling us. The team gets a more complete view of what customers need and how individual requests fit together.
Talk with more customers: AI can help us understand far more customer feedback, but there is still no substitute for talking directly with the people who use your product. There is tremendous value in hearing someone explain a problem in their own words and having the opportunity to keep asking questions.
Keep an up-to-date list of scored features: You should already have a strong sense of which features belong near the top before you start defining one.
Keep feature definitions simple: There was a time when more of the interaction details needed to be documented in writing. Now, once we have the important pieces down, we move into the prototype and figure out the rest there.
Prototype every major capability: We are not trying to make these production-ready. But they need to be functional enough to use and share with others.
Share the prototype with people who will use the functionality: For us, that includes colleagues who know the product well and customers who understand the problem we are trying to solve. Give them time to use it and tell you what they think.
Refine it and gather more feedback: The prototype will change based on what you hear. Share the next version as well and keep the conversation going as the functionality develops.
Product managers who deeply understand the strategy and the customer will become even more valuable as engineering moves faster.
I am still adjusting to all of this myself. It is humbling to realize that I also need to pick up my own pace when I focus on what we are building next. And I know it will take some time. The other way to look at it is that there are no excuses. The gap between customer and code is radically shrinking. There has never been a better time for product managers to go boldly.
Have a feature in mind? Build the prototype in Aha! Builder.
