A unified product management framework
By Phil Barrett
If you want to succeed as a digital businesses you need product management. But understanding what product management is, or what a product manager does, can be difficult. I thought a diagram might help.
Part of the problem is that product managers need to adapt their approach based on context. You might be product managing a startup, searching for a killer business model. Or working in a large corporation, creating a digital interface to an existing business product. Or perhaps you’re managing software that has been around for years, with dedicated and vocal users.
Tactics will be different in each case. But there are some fundamentals about the process that stay true regardless. So I came up with this.
Three phases, four tracks
All in all there seem to be three phases. They can vary in length and importance, and there are different tactics you can employ in each one. But there do seem to be three. I’ve called them product discovery, ship MVP and grow incrementally.
And in each of the phases, you should be doing some of everything: Designing, planning, building and learning from customers.
What changes from phase to phase is the balance and purpose of the activity on each track…
Learn track: In product discovery, you might start learning with some very open-ended contextual research: just watching what your target customers do. But when you’re live, you can look at analytics, as well as the results of A/B tests, plus open-ended usability tests.
Design track: In product discovery, you’ll be doing lots of divergent thinking – coming up with the broadest range of options you can to find the killer approach. But when you’re down the line in phase 3, you’ll spend more time dealing with detailed interface issues such as layout and labelling.
Planning track: When you’re in product discovery, there’s a limit to how much planning you can do. Inspiration doesn’t follow a schedule. And you don’t know how many pivots it’ll take to achieve greatness. But managing your backlog and ticking along with the scrum clock become essential once you move into production.
Build track: In product discovery, for example, you might choose to create no code at all, or to hack together very crude prototypes that are not scalable. But when you’re live and going for growth in phase 3, you’ll be working very hard to create robust, maintainable code.
It’s nice to have a map
The model seems to appeal to people and I’ve had good feedback.
What I like about it:
- You can locate where you are on it, which can help you to understand why certain things are happening around you, and know what to do next.
- You can also locate debates and tools on it. If people are arguing about a topic, like whether you should do AB testing, or what an MVP is or whatever, the cause of the argument is often that they are considering different phases. Doing AB testing makes sense in phase 3, for example, but not in phase 1.
I’m sure the model will evolve over time, and the collection of tools will improve and be refined. Let me know how the model could improve.