Good Product Management is like Poetry
This article aims at helping you build your feature release planning and organize your feedback loops in a timely efficient manner.
What every product manager should know…
If you are a product manager fresh out of college, the first hire to a startup or even the PM in your team, things can be hard at first. In a startup, every statement is only an hypothesis that needs to be tested. Build and manage a product only with hypothesis can quickly become a messy nightmare!
To overcome this issue, it is easier to validate your hypothesis one by one and adjust as you go or even pivot…
One of the most well-known best practice is the feedback loop. It consists in building a feature based on your hypothesis, measure what users are doing with it, learn from those metrics and iterate. Again and again until you nail it!
It is possible to use a prototype and user testing sessions to validate your hypothesis but nothing’s worth massive experimentations with real data coming from a real context. When you have at least one credible hypothesis you have to ship it! Completing one feedback loop will take you 1 sprint. A sprint last for 1 or 2 weeks.
Just make it rhyme!
Do you remember about your poetry classes in middle school ? I’m sure you do remember the rhyme scheme. It turns out that shipping features in a timely manner is pretty much the same…
Writers choose the rhyme schemes in order to control the speed & flow of the poem structure, take control of the audience’s expectations and communicate an idea in the most effective way. As a product manager it is exactly what you want to do with your feature management!
You can manage your product following the rhymes patterns: crossed rhymes, kissed rhymes and followed rhymes. Each feature is represented by one letter and each pattern is 4 sprints long.
The crossed pattern or ABAB pattern is used to ship as many features as possible while collecting enough data to iterate at cruising speed. During the first sprint you have to build features based on your hypothesis A and ship them. The second sprint is about building features based on a totally different hypothesis B and measuring your hypothesis A data. Sprint 3 is used to iterate on hypothesis A, mesure data from hypothesis B and sprint 4 to iterate on hypothesis B.
With this pattern, you have one sprint to build your feature, then you have one sprint to mesure data and one sprint to adjust and improve your hypothesis. It’s important that your hypothesis A and B affect very different aspects of the product. If not, it will affect the relevance of your data. Keep iterating until your data are satisfying. If you can’t nail it after 3 or 4 features iterations, drop the hypothesis.
An exemple with LiPP: add music to videos (A), add text to videos (B), music iteration (A), text iteration (B).
The kissed pattern or ABBA pattern is perfect when you need more time. It is the best pattern for social features because they take more time to collect relevant data and mature. Once you have shipped features based on your hypothesis A, you have two sprints to measure it. You can use this time to fix bugs, refactor code or build incremental improvements which need less feedbacks. Enjoy these short cycles to clean your to-do list.
An exemple with LiPP: search launch (A), incremental improvements (B), bugs fix (B), search iteration (A).
The followed pattern or AABB pattern is the best one if you already have a precise idea of what your customers want, like in BtoB businesses. There are two situations which are a perfect fit for this pattern. The first one is when you need to spend more time fixing bugs and refactoring code. The second one is when you need more time to build a larger feature. You also can spend 2 sprints on one feature then 2 sprints on another. It’s risky because you extend your feedback loop but sometimes you have no other choice to ship big features.
An exemple with LiPP: LiPP TV 1/2 (A), LiPP TV 2/2 (A), refactoring code (B), bugs fix (B), LiPP TV iteration (A).
Sometimes you will need more time to collect data because your hypothesis are based on social mechanics. You can upgrade the crossed pattern with a third hypothesis and you will get an ABC ABC pattern. This pattern works best for BtoC startups focused on building social features and lasts for 6 sprints. I don’t recommend starting with this one as you will have to manage 3 hypothesis at a time.
An exemple with LiPP: leaderboard (A), tags (B), achievements (C), leaderboard itération (A), tags iteration (B), achievements iteration (C).
3/ Implementation of the pattern process
At LiPP we do two product meetings per sprint, one per week. The first one is to define the next hypothesis we will work on. The second one is to choose features we are going to ship to validate the selected hypothesis.
It is really important to take into consideration your team assets when it comes to building features. We have a faster development cycle on Android which is why we ship our new features on Android first. There is no need to put two development teams on the same hypothesis validation. Once you get great results, build and release the features on all your platforms. Keep in mind that sometimes what works on Android doesn’t on iOS.
Roll-out your features to your users to avoid depreciating their user experience. Think about feature flipping if you have a consistent user base. Our data start to be relevant with a critical mass of 1,000 users. Find out what your critical mass is.
4/ Results
Using these patterns, we were able to close 36 sprints, more than 1400 user stories and thousands of tasks in one year with a product team of 5.
Most of the time, we nailed our features in less than 3 iterations (>80% conversion). When we didn’t, we killed the feature (<20% conversion).
As an example, we managed to increase our Open_TV conversion funnel from 5% to 98% by iterating more than 4 times. When it comes to key features, make as many iterations as it takes!
This method helps to keep your product simple. You don’t spend time supporting features your users don’t need. Over and above you are getting closer to the perfect product market fit.
5/ To Go Further
You can play with the model as much as you want. This is just a frame to build a model that truly fits your company. Launch several patterns simultaneously if you have the human resources and sufficient agility. Split patterns by teams to validate as many hypothesis as possible in the shortest time window.
Start writing your hypothesis and give a complexity score to all the features related to it. Then, organise your release planning using the Poetry Patterns. Share your calendar with your team using a spreadsheet, a big board, on even a wall.
Team iOS 1 test hypothesis A and B, keep iterating on hypothesis A and implement hypothesis E validated by team Android. Team iOS 2 test hypothesis C and D which are huge updates and keep iterating on them. Team Android test a social hypothesis E and need to fix bug and to refactor code F, then they implement hypothesis B and C validated by team iOS 1 and 2.
If you want more information about the way we manage sprints and tools we use, you can watch my talk in French. If you want to know how we got over 1M users in less than 6 months, here is our CEO Marc-Antoine’s talk in English.
Thanks to Sophie, Julien and Marc-Antoine for feedbacks and proofreading.
