Why Feature Timeline Roadmap Sucks? — How Can We Execute This New Kind of Roadmap Efficiently? — Ep. 4/4
My story’s goal is to share with you some tips I learned as product manager in B2B SaaS software companies about roadmap and its execution. What are the problems I encountered, how I analyzed them and what solution I found to go through. This topic is hard, I think there is no magic recipe however I hope it will give you some ingredients that will help you in your situation. The story is divided into several episodes. I hope you will find it interesting! Happy reading!
Here is episodes’ list if you want to quickly jump on the one you’re interested in:
- Because We No Longer Make Thing Like In The 90’s — Ep. 1/4
- What Are The Problems Of This Kind of Roadmap? — Ep. 2/4
- How Can We Make Roadmap Great Again? — Ep. 3/4
- How Execute This New Kind of Roadmap Efficiently? — Ep. 4/4
Execution engine should be composed of two parallel tracks: discovery & delivery.
Keep in mind that the real purpose of the methodology is not the methodology itself. It is to help you to reach Key Results (KR) defined, deliver end-users outcome and business impact by being empathic with end-users and by doing high pace iterative and incremental discovery and delivery.
Concerning discovery methodologies (Design thinking with design sprint etc.) and delivery methodologies (Scrum, Kanban etc. with the help of complementary methodologies like story mapping), start by using the one that best fit your team by the book and adapt it as you learn.
Start the discovery with your squad and optional guests for your 1st problem to solve. Remind them the problem and KR you defined to measure your success to resolve it. Then ideate on potential solution.
Then, test & iterate potential solutions with beta testers with a strong focus on risky parts. Do your best to prototype potential solution without a single piece of code by doing low-fidelity mock, animated user flows etc. Goal here is to fake it in order to know if it’s worth building.
If it works, this means that everything the squad works on after will help you to progress… No waste!
Every product manager’s goal is to minimize output and maximize end-users outcome and business impact, Jeff Patton
You can start the delivery once you’ve found potential solution that are worth building.
Remind your squad about the problem, the potential solution you selected and why. Then, continue with a talk & doc session to break done potential solution in user stories with acceptance criteria.
Once ready, user stories can enter development pipeline until they’re done.
Then, you activate potential solution only for relevant beta testers and internal teams in order to measure, learn and iterate until viable. A viable solution is at the intersection of feasible, usable and valuable.
Remember, you have defined the destination with KR, not the road to reach them. You should pivot when needed as you learn by adapting potential solution and test new ones to reach KR defined.
Story mapping methodology is useful to not get lost on the path to iterate until viable by keeping an overview and focus on end-users experience.
A feature flipping solution is required to:
- Show an hypothesis minimum solution only to beta testers.
- Do progressive roll out (10%, 20% of your customers etc.) to continuously measure and learn to check if end-users outcome and business impact are still there as customers subset increase
- Limit risk due to unanticipated side effect for example
On a technical point of view, Integration and Deployment should be done Continuously (CI/CD) to go live, measure and learn as fast as possible.
Be as much careful with communication to internal teams than with your end-users.
Concerning internal communication, the squad has the latitude to build what’s best to reach the Key Results defined so it implies frequent communication (every week for example) to other teams in order they know and be prepared on what’s coming on. OKR progress report and delivery rituals like product demo are powerful tools to use.
Like I said earlier, internal teams have to be able to show end-users what they can do and answer their questions at day 1 to ensure satisfaction.
External communication should be managed by the product management and product marketing team and split in release. Release process should be defined between product team and other team in order to be effective. Your end-users and internal teams have to follow the pace and you can’t communicate all features with the same guidelines because potential high-impact features will get lost in the noise and lose their impact. You can communicate for example every month new low/medium impact features in a minor release and every quarter high-impact feature in major release.
That’s not finished! In fact, it’s the beginning of your feature life. And new features are like your children, you have to support them.
As I said earlier, customers on-boarding on what’s new is key in order end-users know that there is a new thing, understand what they can do now and how. You should continuously follow the feature in order to check since general availability if it continues to reach the end-users outcome wanted.
If outcome decreases, you must understand why and decide the action: new communication, frequency and/or adoption improvement or kill the feature.
Killing a feature should remain a possibility, possible causes: usage decline & it is not a priority to enhance, it costs your user & internal teams because it becomes too complicated to use, it’s costly to keep up… Even if you did your best during discovery, it happens, you should remain pragmatic even if you were part of the building team.
You have 2 ways to improve your product: add new or improve features. Don’t get lost in feature adding.
End of the series, thank you for reading, I hope it was useful! Don’t hesitate to share feedback at bottegal.brice@gmail.com and have fun!
Here are some resources to learn more:
- Book User story mapping by Jeff Patton with Peter Economy
- Book Inspired: how to create products customers love by Marty Cagan
