Building an MVP and launching the first version of a product is the easy part—it’s more difficult to manage a product in its maturity or decline stages. The maturity stage is also where you’ll make the most money, and where churn really hurts.
So how do you manage your maturing product? To find out, we recently hosted a webinar featuring Janna Bastow, CEO and Co-Founder of ProdPad. She talked about company objectives while avoiding becoming a “feature factory.”
Can you give us an example of how users may shift over time?
Sure, I can tell you how our own users have shifted. In the early days of ProdPad, our users were simple. They were early adopters, eager to try new product. But back then, the scope of our product was smaller. I’m happy to say that a lot of those early adopters are still with us, but it’s very clear that their needs have changed. Nowadays, they need more advanced functionality to get the most out of their product. They represent a completely different user persona.
At the same time, we still have new people entering our world. And in order to continue succeeding, we have to cater to these people as well. It’s basically like having to build two products.
What should companies be doing in a product’s growth versus maturity stages?
In the growth stage, your focus is on getting product market fit. You’re aiming to get more downloads or trials, first-time buyers or subscribers, or getting new users to spread the word. But in the maturity stage, you’re catering to existing customers as well as new ones. You’re looking for ways to get more revenue and push churn to new lows. To stay competitive, you need to minimize costs and streamline your processes.
This is a really awkward switch for most companies. It means that a lot never really reap the benefits of having a cash cow as their mature product.
How can companies avoid becoming “feature factories”?
A growing user base means more problems to be solved and new opportunities to expand. And this often has the unintended consequence of conditioning companies to become feature factories. The solution is to focus on hitting company objectives and solving real problems over just delivering features.
What I always tell customers is to ditch their timelines. Instead, focus on “time horizons.” It’s subtle, but instead of a single line marching forward, thinks in terms of three buckets.
In the first bucket, the current term, you’re pretty granular about your focus and scope. This is the stuff that’s being built right now. There’s not a lot of flexibility, but that’s okay because your team does need some certainty and structure.
The next bucket is your near term, where you might outline initiatives that have a wider area of focus. It balances the certainty your team craves with the flexibility that your product strategy actually needs.
And the last bucket is your future, where you’re more likely to have placeholders rather than fleshed-out ideas. These are the initiatives that you think make sense based on your product vision, but you don’t have clarity on how you’ll actually deliver them.
You mentioned focusing on objectives rather than features. Can you give us examples?
These should be outcome-based goals that are tied to your company strategy. Your objectives should act as guardrails to keep everything pointed in the right direction. For us, ProdPad is a SaaS tool, so these are examples of what we might use:
- Research & Development
- Reduce churn
- User growth
- User experience
Your product might use different objectives. The important thing is to focus on outcome over output. Measuring output is like something counting how many story points have been completed. Measuring outcome means you’re tying those results back to the original company-level goals.
How should companies deal with the burden of suggestions, feature requests, and bugs that may pile up as their products mature?
That beast of a backlog can cause all sorts of problems, especially for your tech team. The solution to this is actually remarkably simple: Just split your backlog into two parts.
First, you have the development backlog, which is the stack of specs that are ready and approved for development. This may include tickets, bugs, and dev ops tasks. This backlog should be relatively short and allow the developers to focus on the task at hand. This is good for your execution.
Second, we have the product backlog. It’s the list of all the things you could do in order to build the right product. It will include customer requests, suggestions from the team, insights from experiments and prototypes, etc. It should be transparent so the whole team can add to it. This backlog is key to your strategy.