The RocketChart Product Management Engine — How we’re building our SaaS
--
Managing and forecasting cash flow has always been a challenge for startup founders. Most of them rely on laborious spreadsheets that are time-consuming and error-prone. Yet, cash flow is the lifeblood of startups.
At RocketChart, our mission is to make cash flow management easy, automatic and predictable. Our goal is to give founders peace of mind by knowing their actual, and future cash position.
We are a team of 3:
- Elie is a full-stack software engineer
- Marc is also a full-stack software engineer
- I (Philippe) do growth, design and customer support
And this is how we do Product to tackle this mission 💥
Context: turning our biggest weakness into strength
The idea behind this product struck in July 2019. During the first 2 months, we focused on getting a clear picture of the pain-point by chatting with +300 business founders. Then we started to build the product. We launched the Beta in December. RocketChart was born. You can discover the complete journey in these very detailed and transparent articles, where I share how we went from SaaS idea validation in one day to Beta launch.
Since the very beginning, we have one precious and scarce resource: time. Elie and Marc have day jobs. They only work on evenings and weekends. This is the price to bootstrap a company. Thus, the time to build the product is very limited. This is a weakness, but we turned it into our greatest strength.
First, because time is confined, we do absolutely zero meetings, zero bullshit workshops to debate the color of a button. Marc and Elie are 100% focus on building the product. They get shit done, delivering task after task. Second, also because time is limited, we have to focus on the most impactful tasks and features. This results in a sharp product, without buttons everywhere or useless features. Third, Elie and Marc have the continuous opportunity to take a step back, every day. Before working on a task at night, they have all the day to imagine the clever way to deliver. They can’t rush ahead and write bad code.
Now that you have context, let’s dive into our product management engine. We are using ClickUp to supercharge this engine.
Fill the Product Backlog with well-defined tasks
We are not creating RocketChart, our lovely customers do. We never pull out new features of our own hat. They all come from our users because they want to be more successful using the product. Since the very beginning of our journey, we’ve tried to create a close relationship with our beloved users. It has produced a virtuous effect: they are very attached to give us feedback and insights about how they want RocketChart to evolve. This is very powerful in making sure you deliver killing features.
There is a common belief in the product management field saying users don’t know what they want until you show it to them. I disagree. People know exactly what they expect: they know their desired outcomes. What they sometimes ignore is how to express and explain them. Your ultimate goal is to help them formulate it, to detect the desired outcome hiding behind any customer feedback. Henry Ford once said: “If I had asked people what they wanted, they would have told me, ‘A faster horse!”. For sure people did not mention they wanted a combustion engine, but they had told Ford they wanted a faster mode of transportation to save time. The 5 Whys method is effective to dig deeper and find out what is the core desired outcome.
Once the desired outcome is explicit, we write an overall user story attached to it and I create a task in our backlog with the label “feature request”. We track the number of times the feature is requested and appoint it to each task to help prioritization. Then, I simply work first on the most requested features. This ensures to ship features that impact the greatest number of users.
To remain fast and focused, the overall user story is broken down into bite-sized user stories. We have a strong overarching vision of what we are building thanks to the +300 founders talks we had since the beginning. Thus, small user stories could still be connected to the long-term vision. I guess we are mixing a sense of focus and purpose here.
Before embarking on design specifications, we imagine the Minimum Viable Release (MVR) of each group of small stories. In short, it is the simplest solution to help users obtain the desired outcome. The goal of the MVR is to invest the minimum amount of time to confirm we are building the feature the right way. Then I design the MVR. Based on this, Marc and Elie estimate the time to ship the task. In the end, a task is a combination of many pieces of information 🤯
Once task details are complete, we move the card to the step “To Prioritize”. This step is just before the “Work In Progress”. The following schema summarizes feature request creations in our backlog.
Regarding bug reports, we also use a specific template. The goal is to ensure fast resolutions. First, the component or element concerned is clearly identified in the task. Then, we decided a bug can only be a task if it is repeatable. So bug tasks include the step by step process to replicate the bug. It’s convenient for Marc and Elie. It helps them to quickly detect where the bug comes from. Finally, to avoid confusion, I describe the observed behavior in comparison to what is normally expected. Below is an example of a real bug issue, with the template used.
With this product management engine, we can fill our backlog with well-defined tasks. And cards are waiting in step “To Prioritize”. Now, the challenge is to decide which task we move in “Work In Progress” 🤔
Get tasks prioritization right
Each company wants to deliver big-impact features for users that request less effort for the team. These are the Holy-Grail of Product Managers. To be honest, we don’t use a killing framework to identify game-changing features. The cornerstone of our product management lies in cutting down stories into the smallest piece possible and delivering the MVR. This speeds up our product engine. But I have to highlight a small trick we use to prioritize better.
For each small story, we attribute an estimation of the Value perceived by users. Time estimates of Marc and Elie immediately highlight the Effort required to ship the feature. We’ve automated calculations in ClickUp. Now we can draw the classic “prioritization matrix”:
Prioritization is now straightforward. First focus on Quick Wins, then find a subtle mix between Big Projects and Small Increments, and never touch the No-Go Zone. Easy right? Not so fast… The whole process relies on projections and estimations. Humans are very bad at this game. Especially if we don’t have past experiments to compare evaluations. We tend to underestimate the effort required and overestimate value and benefit. This phenomenon has been theorized in the Planning Fallacy. In other words, our poor predictions result in both time overruns and benefit shortfalls. Thus, projects tend to be more costly than we think and deliver less value. Looking back at the “prioritization matrix”, things look more like this:
Thanks to this matrix we automate tasks prioritization for feature requests. But what about bugs? Many users report bug issues on the App. Nothing can’t be perfect the first time 😅 We decided to put bugs on top of the priority. Meaning that if a user reports a bug, then this task skips the priority to other tasks in the ToDo list. Product backlogs are full of bugs in many companies, resulting in an accumulation of unpredictable side effects months or even years later. Instead of losing time in the future, we choose to invest time right now to fix each bug. It’s easier when your product is still small. Also, developers have an unfortunate tendency to skip bug fixes. Particularly if they have other tasks assigned. You know it will be a painful game to dig and fix a bug. Marc and Elie don’t want to skip bugs.
As you see in the diagram above, we don’t use sprints to manage our product. The reason is, we don’t want to create a sense of urgency. Instead, continuous delivery creates a perpetual stream. We call it our Product Flow.
This Product Flow is now set up and generates momentum around it. This momentum drives our overall product management process. The flow must remain continuous at all costs. You will discover why in the following part.
Bet on momentum rather than urgency
We ran RocketChart Beta in December 2019. Early users’ feedback revealed our product was completely failing at delivering enough value. We needed to work on many improvements to get closer to a must-have product. I decided to set a deadline to release the new version: mid-February 2020. During a month and a half, we worked very hard to reach this objective. Elie and Marc were coding like crazy nights and weekends (they have a day job). And we finally released our new version 🎉
But we quickly realized our backend wasn’t scalable at all. After 8 users on board, we can’t get more. The app was laggy. It confused the overall user experience. Pressure and urgency led us to an illusion of speed that later collapsed with mediocre results. It hurried delivery and prompted us to cut corners. However, that cost was difficult to predict and measure. In the end, we chose urgency. And this doesn’t work in the developers’ world. As Elie once said: “Setting deadlines to urge developers has never worked — it’s universal. Creating a sense of urgency blocks developer’s creativity”.
We learned one critical insight here. If we want things to move fast, we need a sense of momentum instead of urgency. Whether it is building a new feature or solving a bug, the developer’s work is more creative than simply technical. When developers deal with product troubles or new feature ideas, they have to find the best solution among all the infinite possibilities. They give free rein to creativity. And a creative mind needs space and emptiness to express. Elie, Marc and I are convinced that the developer’s work is part of the continuous flow explained just before. And preserving this flow is critical. No one can cut it. Otherwise, you break the momentum and start fighting against the flow. Meaning that you spend more energy and the team gets exhausted 🥵
As you’ve read, we broke the tech work into bite-sized chunks. I (Philippe) prioritize the tasks. When Marc and Elie deliver the work, they put the card in “Done”. Then, I try out and accept or reject the task as quickly as possible. This is the “Under QA” step. I frequently check Clickup to know if there is something to test. Responsiveness has a palpable impact on our small team for sure. We have become a delivery machine. Each task accepted fueled the next delivery and fed the overall flow. We never hurry. We never cut corners again.
An undisclosed benefit of momentum is, you keep your tech team healthy. If you protect them from urgency, they will never run out. Their minds stay sharp. They release a high-quality product and your overall delivery speed increases. Your customers benefit from this and they reward you with word-of-mouth or kind messages. Feeling customers happy about the product boost developers’ confidence and getting positive feedback on their work motivates them. The momentum loop is now close and becomes virtuous, making you a killer team.
Product management is not just about tasks prioritization
Product teams rarely struggle with feature requests and product enhancement. As you know, the real challenge is prioritization. Your backlog is full of tasks: bugs and feature requests. The question is: how do you decide what to work on, and in which order? The first logical step Product Managers do is to create scoring frameworks. As you’ve read through this article, it allows you to automatically rank tasks and helps you decide what to work on.
But I recently discovered that building a product roadmap is way more complicated. For most startups, the actual product is only a fraction of a broader vision. But in the meantime, startups have to survive to achieve this vision. So business results are essential. And on a daily basis, customers are concerned about being successful with your product right now. That’s why they give you customer feedback. Building a product roadmap is finally a precise balance of these 3 dimensions: customer, business, and vision perspectives. And the tricky part is, they are often contradictory.
If you only take into account the customer dimension, you will improve your product to make it more used by your customers. For sure they will be more successful. But will your overall business metrics be improved? Business is about maximizing profits. Generally, it breaks down to Acquisition, Activation, Engagement, and Monetization. In 90% of cases, expectations of your customers won’t be aligned with business expectations. Then, add the vision dimension to this already hard product mapping: vision is about long-term objectives. Customer and business perspectives are usually short-term initiatives and thus go completely against the vision dimension. Each of the 3 dimensions produces very diverse and conflicting priorities. It results in a tremendous tension between the 3 perspectives. In the end, we believe Product Management is an Art, in which a meticulous balance is found between Customer, Business and Vision dimensions.
We came to this conclusion very recently. Some concepts need further investigation. But one thing is sure: our Product Management Engine will keep evolving in the coming months.
This Product Management Engine helps us go from 0 to Exit within 2 years 🥳 Yes, we’ve been acquired. Here is the complete story.
Thanks for reading me. I hope you get value from this transparent article. If you want to discuss Product Management, feel free to add me on LinkedIn. I would love to chat with you. For those who arrived here by a mystic or divine intervention, I hope you enjoyed and I’d be happy to answer questions. Let’s chat on LinkedIn! 🤗
Useful resources about Product Management
The following are some articles that helped us set our product management process. If you want to dig deeper into product management and discover how other Product Managers are dealing with product roadmaps, I recommend you to take a look 😉
How to Prioritize a Roadmap -> here
Why impact/effort prioritization doesn’t work -> here
2 articles from Mathieu, Head of Product at Brigad -> here n°1 and here n°2
There is a very high probability that your startup’s cash is managed and forecasted on highly manual spreadsheets. If you don’t find it laborious and time-consuming, then keep doing this way. Otherwise, you can try our powerful tool here 🤗
