Product Management
TO BE IMPROVED
👋 Intro
Let’s remind ourselves quickly what are the main responsibilities of PRODUCT. In this amazing blog article, Marty C. explains the 4 main risks of product and who’s responsibility it is to mitigate those risks.
Value risk (will people buy it, or choose to use it?) → product manager responsibility
Usability risk (can users figure out how to use it?) → designer responsibility
Feasibility risk (can we build it with the time, skills, and technology we have?) → tech responsibility
Business Viability risk (will this solution work for the various dimensions of our business?) → product manager responsibility
🎯 Our ambition for product
The principles on which we base our process are quite simple:
we build features that matters, thus we know why we build them → focus on the problem we're solving
we co-create ; there is no such thing as creating alone → great teams are cross-functional teams
testing and iteration: when we fail, we fail small ; when we succeed, we succeed big time → iteration is the key
great products are the results of empowered teams → we innovate through teams that are given a mission (missionaries not mercenaries)
Focus on the outcome, not the output. Feature factories are no good for anyone. They are just a big cost center in your company.
📚 Theory
Our work is based on the work of others (of course - we are not barbarians). The main influences are:
The Lean Startup - Eric Ries
Inspired: How to Create Tech Products Customers Love - Marty Cagan
Empowered: Ordinary People, Extraordinary Products - Marty Cagan
Shape Up: Stop Running in Circles and Ship Work that Matters - Basecamp
👨🏫 High level concepts
For long, we've worked in silos with the business department having its roadmap, the marketing department having its own roadmap and the IT having its own roadmap which was based on the two first ones + a technical roadmap (with nerdy stuff). While this has worked in the beginning (2 first years) with a limited size team, it soon started to create some frustrations on all sides. How do we prioritise the time for development; how can we give good feedback on where we stand on the dev of the projects; how can we show the status of features that are more complex than planned and needs more investigation; how can we make sure that the scope and solution are correct before starting the engineering process? Now we know better...
Business & IT share the same Roadmap and the same priorities ⇒ Thus we only have one place to gather all information & documentation.
The purpose is to shape ideas into workable features & projects, and then develop them in a quick and elegant way. This is the place where we define the concepts, the scopes, the priorities and the requirements for large overarching initiatives.
👋 Remember: understanding the root problem, co-creation of empowered teams and small iterations are the key concepts for success.
We have 5 types of cards - 2 raw concepts & 3 types of work:
💡 Ideas are raw & unclear concepts we would like to work on someday. They're not on the product table by default. 🗣 Feedback are the inital demand of a user / operator. They imply a pain that needs to be solved.
🏗️ Build are the new features & projects 🏃♂️ Run are the improvements & bugs to existing features 🛰️ Tech are the tech / nerdy projects for the future proofness of our stack.
A side note on ideas vs product features
A raw idea is by nature not something that is yet ready to be build. The reality is that we have a lot of ideas but not all of them are worth being built. They need to pass through a few cleaning steps first.
What is the overarching problem? As long as we haven't really understood what pain we're trying to solve, then we just cannot start building. Agreeing on that is the root of everything.
Now that we know what pain we're facing for the end-user, we can decide if it's worth building. What is its impact and what is its priority!
Knowing the problem, the impact, the priority → do we currently have the resources and what appetite do we have for it. In other words: how much time are we willing to allocate!
Our default response to any new idea that comes up should be: "Interesting, maybe someday". In other words, a very soft "no" that leaves all our options open. We don't put it in a backlog. We give it space so we can learn whether it's really important and what it might entail. It's too early to say "yes" or "no". Even if we're excited about it. Saying "yes" to incoming requests will end up with a giant pile of work that only grows → never-ending backlog ! It’s really important to learn to prioritise work well and to be able to explain clearly why we did or did not prioritise something. We don’t have unlimited resources nor time. Prioritising is the subtle art of deciding what not to do.
Last updated
