Building an MVP and launching a product is actually the easy part. It’s much more difficult to manage a product in its maturity or decline stages, so I wanted to tackle the challenges of a product that’s past its initial growth stage, and share some tips on:
– How to avoid becoming a feature factory, while taming your beast of a backlog
– How to use your roadmap to drive experimentation to hit company objectives
– How to disrupt yourself before someone else does
The Product Lifecycle
We all know the product lifecycle chart. While many of us are familiar with the uphill battle and the grind involved in getting traction and any growth towards product/market fit, the launch and growth phases represent a small fraction of the overall life of a product.
The MVP and initial fast iterations and pivots we usually talk about? That usually happens at the very beginning. But in reality, it’s not where most product managers spend their time. Most product managers have adopted an existing product that’s closer to the maturity end of the chart; one that has a pile of existing customers and constraints, a good chunk of tech debt, and invariably a messy backlog of features and bugs that they’ll never be able to fully work through.
But if you look at sales volume, it’s at this maturity stage where most of the money is made. And it’s at this stage where churn really starts to hurt. After all, it’s easy to hide an ugly churn rate when you’re whipping up fast growth, but it’s a mathematical fact that any churn rate over 0, as you begin to saturate the market, will eventually flatten this curve out. It’s when your product is mature that churn really starts to bite back.
And yet if you look at what you typically read on Medium and other startup-savvy publications, you’ll mostly read about launching products and optimising for growth. No one seems to write about managing products that are reaching maturity, or god forbid, the decline stages.
Which is a shame, since it’s exactly at those stages when things start to get really hard.
The reality is, if you want people to use your product long-term, your product will have to grow with them.
Each day that your product is in existence, the people who use it change and progress. They get accustomed to how it works and fold it into their processes. They get better at using it, and develop needs for more advanced usage.
And with each day, you have new people entering your world as first-time users. This is great for growth, but they represent an entirely different sort of user.
When we first launched ProdPad, our users were simple: early adopters who were eager to try a new product and happy to put up with being beta tested on. They gave prolific feedback and built relationships with our team. Happily, some of those users are still with us today, but their needs have changed entirely. These days, they proudly show examples of how they’ve built their processes around our tool, are adept at instructing others (and us!) on how to use it. They regularly ask for an increasingly complex set of features to fit their advancing needs. They’re the same people they were several years ago, but represent different personas now.
And yet new users join each day. These are people who’ve never tried the product before and don’t know their way around. And unlike the early adopters, they come out of the gate with higher expectations than the folks we encountered years ago.
It’s like having to build two different products at the same time.
In the growth stage, your team is focused on getting product/market fit. It’s about cracking those quick wins and boosting the wow factor. Whatever it takes to get traction and prove your product has a place in the world.
In the maturity stage, you’ve got existing and new users to build for, built-in constraints and technical complexity, politics and people to work around.
Maturity Comes with Problems
Problem: You’re a Feature Factory
If you’re a maturing company, you might find that you’ve become a feature factory. This often grows out of old habits that were once good, but are now misguided. In the early stages, each new feature brought more downloads, signups and sales, and blasted you forward beyond the competition. You were hyper agile and pushed code and new features weekly, if not daily! You out-paced your competitors, and know how to move fast.
But in the later stages, the goal isn’t to just deliver features! In fact, each new feature weighs you down, resulting in a Frankenstein of a product. Your old agile habits have led you astray.
This is why it’s so important to think objectives, not features! In order to survive, you’ll need to have a renewed focus on hitting company objectives and solving real problems, instead of just delivering features. Inherently, teams understand this. They know that a big pile of features isn’t what their customers want or what their business needs. And yet it’s a pattern that happens over and over again.
I blame the roadmap. Roadmaps aren’t inherently bad… in fact, they can be a remarkably effective tool for communicating product strategy! And yet, a badly done roadmap can pave the way to a feature-filled product death.
So I implore you all to do this with me: Ditch your timeline roadmap.
Sure, this format of the roadmap makes you look good today… your board and your boss love seeing this level of certainty nailed to the wall. but it’s setting you up for failure.
See, the problem with a typical roadmap is that it pits Time vs. Things to do, with Time represented on the x-axis, creating this timeline along the top. That’s all well and good at first, especially when you’re representing your short-term projects and your upcoming releases, where your team has given decent estimates and is on board with the given release dates. But the more you add to the roadmap and the further down the line you get, the harder it becomes to manage.
Soon, you end up with a pile of features, each with given durations and due dates, implied simply from the very layout of the roadmap, with that timeline, ever marching forward along the top. And we all know that these aren’t tightly estimated, fixed-scope projects. These estimates and due dates are coming out of assumptions piled on top of assumptions.
You assume you know how long each of these features is going to take. This game is easy in the short term, when you’ve got a clear undertanding of what the developers on your team can take on and they’ve helped you craft your estimates, but the further out you go, the less you’re going to be certain.
You assume that nothing else is going to come in and disrupt this timeline. No changes in the market, no new competitors, no fresh ideas coming from customers, no need for iteration.
You assume that each of these features will work as soon as they launch. You allowed three weeks to build that checkout page? Then at the end of three weeks, it’ll be converting exactly as well as expected, and now you’re free to move on to the next thing.
You assume that each of these features actually deserves to exist! That they form part of the strategy and therefore should be codified.
Overall, you’re making one big, dangerous assumption: That nothing is going to change. What could possibly go wrong?
This pile of assumptions could lead you towards a bunch of unhappy times. The made up release dates end up sending you and your developers on death marches, trying to meet the deadline. Your sales team and your customers have set expectations on what’s going to be delivered and when, while you’re missing market opportunities and possibly even building entirely the wrong things. This all makes for sad product managers.
So is there a better way?
3 Steps to Ditching Your Timeline Roadmap and Getting out of the Feature Factory
Step 1: Set your product vision
Step 2: Map out your objectives. These are outcome-based goals that are tied to your company strategy. You might know them as KPIs or OKRs, or just as Objectives. It doesn’t matter what you call them – whatever works best for you and your team. Your objectives act as guardrails to keep everyone pointing in the same direction and working on the right things.
Step 3: Change out your timeline for time horizons. It’s subtle, but instead of a single line marching forward, think in terms of these three buckets:
The future column is less about specific initiatives, but more around outlining the problems that you think need to be solved in order to fulfil your vision, but still need to be validated.
And that’s key: your roadmap is for validation. Your roadmap is a prototype for your strategy.
Just as you might validate a feature by drawing up some paper prototypes and showing them to your customers and then starting again based on the feedback, your roadmap is a starting point for conversations around what needs to be included in your strategy.
Result: Lean Product Roadmap
By putting these three elements together – your vision, your objectives, and your time horizons – you can build a Lean Roadmap.
The value of this roadmap format is that it takes the focus off building features and hitting delivery dates, and helps your team strive towards solving problems.
Problem: Your Backlog is a Beast
Nothing stifles innovation like a to-do list as long as your arm. And yet this is a state that so many teams get stuck in. In their Trello board or their JIRA wall, they can work through a handful of tickets at a time, and yet there’s always a massive, bloated, vertigo-inducing column of tickets that are lined up to do next.
It stresses out the development team who are looking down the barrel of a million upcoming tasks, many of which aren’t even properly defined, and it freaks out the non-tech team who are just wondering why none of their ideas ever seem to see the light of day.
The solution is remarkably simply. Break the backlog up into two parts: The Product Backlog and the Development Backlog.
Here’s where a lot of people get confused, because “backlog” is a broad term. Here’s what I mean by each:
Development Backlog: A small list of self-contained and estimated specs, which are approved for development, prioritised, and ready for the next available developer to pick up and crack on with.
Product Backlog: A list of all of the things you could do. You’ll never complete everything on this list, and it’ll always be in a constant state of flux. It’ll include customer requests, suggestions from your team, through to insights from your experiments and prototypes. It should be accessible by your team, to both contribute and follow along on progress – your team should be helping to build and flesh out the ideas in your backlog. This is your space to prototype and spec out ideas, map them to your objectives, and track their progress until ready for production.
A tidy development backlog is crucial for solid execution, while a transparent product backlog is key to your strategy. Split your backlog into these two parts to avoid having a beast of a backlog and not getting the best of either world.
Problem: Experimentation Scares you
We’re all familiar with the Build-Measure-Learn cycle. It seems simple; it is simple. That is, until you’ve got competition nipping at your heels, a growing base of customers asking for more and more, tech debt creeping in at the edges. Your company enters a panic mode, trying to shovel features and fixes out the door, and neglects to focus on anything other than the Build part.
They forget the other two parts of the flow: Measuring and learning!
And so instead of Build-Measure-Learn, this becomes Build-Build-Build, also known as the Build Trap.
It important to battle this urge to build constantly, especially as the product matures. The key thing that’s often missing is simply creating the time and the space to validate the work that’s being done. It’s not that people in the team don’t understand it’s important to make sure that the right metrics are moving, it’s that they often don’t have the permission and time to stop building, and actually do the measurements.
One solid way to do this is to adopt some form of dual track agile. There are a lot of ways to interpreting dual track agile, but the essence is that you give figuring out what to build as much importance as the building process itself. You start with a discovery track to find out if a product idea is good and if it makes sense to build. Successful findings from the discovery track are added to the backlog of the delivery track.
Having a dual track approach gives you permission to spend the time in discovery, instead of feeling the pressure to constantly deliver. Done well, this gives you the best combo of speed and learning.
Don’t trash your roadmap!
I see a bad habit all the time: You’ve released something, so then you close all the tickets in JIRA, crumple up all the sticky notes on the wall, and start moving on to the next thing. This might seem good for keeping up cadence, but bad for ensuring that you’re making an impact.
After all, just because something was launched, doesn’t mean it’s solved the problem you wanted it to!
Fortunately, your roadmap can help give you this space. As I showed earlier, each card is a problem to be solved, and is tied to an objective.
Each card, will in turn, be connected to a list of experiments that could be run in order to solve that problem, and impact that objective.
You can use your roadmap to give you an overview of progress on ongoing experiments. And once a project is done in development, don’t just throw out these results or tuck them away somewhere you’ll never find them again…
Instead, move them to a list of completed cards.
The purpose is to give you a space to track what was released and when, and then outline the results. Did it solve the problem and move the metric you were hoping it would?
By making the Completed section of the roadmap a part of your process, it provides a space to show off the value of the work done.
You know nothing.
It helps to remember that it’s not your job to have all the answers. You’re supposed to know less than your colleagues. Instead, focus on asking the best questions, and creating a safe space for everyone to contribute.
It’s important for a team, at any stage of the product life cycle, to have psychological safety. This is about making people more comfortable about speaking up,
reporting errors, and pitching in to help with the product.
You can help build this safety within your own team with just a couple tweaks to your language which will help create the right environment:
How might we? Phrase questions so they begin with “How might we…”. It turns the issue into a collective problem; it supposes instead of asserts. And it works really well in conjunction with:
I bet… As a product manager, you’re going to be wrong, a lot. “I bet” gives you permission to fail and try again. After all, it wasn’t you that was wrong
– it was your hypothesis. And now that you know what doesn’t work, you’re free to test the next bet.
It’s subtle, but these tweaks in process and shifts in language set the stage for psychological safety, allowing you to build more confidence in the experiments you’re running.
Problem: You’re About to be Disrupted
If you’ve been so tenacious and lucky to end up with a mature product that’s spinning cash, you can be sure that you’ve got some fleet-footed startups right on your heels.
Most companies start off on the far end of this scale, where they’re incredibly nimble. They don’t have customers yet, there’s no tech debt or other impediments to iterating quickly. The founders have read Lean Startup and are ready to use it in anger.
On the opposite end of this scale, you’ve got your giants. Slow-moving, risk-averse organisations that are pinned down by government regulations and obligations to their vast pool of stakeholders. Slow or not, these organisations often don’t have an immediate incentive to become more nimble. Those regulations are a barrier to entry for other companies, and the value they add to their existing shareholders translates to massive piles of cash. It’s nice to be at the top.
But the competitive field is always changing. Upstarts are always chewing away at the edges, taking advantage of loopholes and new technologies to capture small parks of the massive market. Larger, slower companies need to be on the watch out, or else those new products will eventually render their mature portfolio obsolete.
The shift from nimble to slow is pretty much inevitable for any maturing product, but the most successful companies have found ways to compete with these upstarts.
They need to disrupt themselves before someone else does.
I’ve surfaced four models for doing so:
The Google: Google is famous for its 20% time. It gives staff the equivalent of one day per week to work on whatever they like. It might seem like a waste of resources, but some of its core products, like Gmail and Maps have come out of this. Now, 20% might be too much for a lot of companies. Perhaps you can try to carve out just 2%, or even 0.2%, and see what comes out of it.
The Hackathon: The Hackathon is just as good for building disruptive products as it is for team building. Give your team a time-boxed week of freedom to put together a simple product. It could very well be the start of a new, profitable business line!
The Lab: The Lab is an approach used by a lot of large enterprises, usually trying to go through some “digital transformation”. The lab is a small division of a large company that looks and acts like a startup, but has the backing of the corporate parent to fuel the growth of any prototype that shows interest.
The Facebook: Facebook has one of the largest user bases in the world. But it never releases something to everyone at the same time. In fact, it can segment its users into tiny groups and test and release new features to just one group at a time. This removes the risk of launching something to everyone, and allows it to experiment way more readily as a result.
All of these are tactics that can help your company disrupt your own maturing product before it enters the decline stage.
Your goal is to breathe new life into your maturing product, by adding more value or expanding your market.
If done right, you can extend your product’s life and expand your revenues even further.
Beat the feature factory by ditching your timeline roadmap and focus on solving real problems. Conquer that beast of a backlog by separating strategy from delivery and excelling at both. Learn to love experimenting again by building in space and permission for validation. And remodel your company so you can disrupt yourself before anyone else does.
And that’s how you can grow up Lean and stay nimble even as you reach maturity.