Product Management

πŸ‘‹ 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:
  1. 1.
    we build features that matters, thus we know why we build them β†’ focus on the problem we're solving
  2. 2.
    we co-create ; there is no such thing as creating alone β†’ great teams are cross-functional teams
  3. 3.
    testing and iteration: when we fail, we fail small ; when we succeed, we succeed big time β†’ iteration is the key
  4. 4.
    great products are the results of empowered teams β†’ we innovate through teams that are given a mission (missionaries not mercenaries)
  5. 5.
    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:
  1. 1.
    The Lean Startup - Eric Ries​
  2. 2.
    Inspired: How to Create Tech Products Customers Love - Marty Cagan​
  3. 3.
    Empowered: Ordinary People, Extraordinary Products - Marty Cagan​
  4. 4.
    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.
Product management process

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.