Startups fail all the time, for countless reasons. Too short runway, unqualified management, conflicts between founders are only a few of the many reasons. Frequently, though, such a fate can be avoided, thanks to the process called Product Discovery and its variations. One that has worked for our products over and over again is an Agile Inception that then grew into the BRIDGeS framework.
Is Product Discovery necessary?
Since Eric Ries’ bestselling “Lean Startup” was launched back in 2011, lots of wannabe entrepreneurs jumped on an MVP bandwagon. They would quickly build an agile product or service and start promoting it online. They would chase open-mic opportunities and get a little brother, distant uncle and that one nerdy friend from high school on board as first users. A demo would likely get some early traction in the first weeks. “Incredible, it works!” – a founder would think.
Users would provide more (or less) valuable feedback, the team would iterate over and over again. They would frown upon any advice about doing a proper product discovery. “There’s no time to lose” – they would say – “we’ve already found our product/market fit.”
What could then follow are, of course, explosive growth, awards, VCs lining up in front of the office and a great IPO in the foreseeable future.
Or, unless your last name is Musk, a spectacular collapse would likely follow.
To avoid such unpleasant surprises, many teams choose a different approach. Before they write a single line of code, they retreat for a short while and focus, with more or less success, on the proper product discovery. They try to answer questions such as:
- Who are the potential users of a product? Will it solve any important problem for them?
- Are we capable of building this product? Do we have the right skills and resources?
- Is it the right approach to solving such a problem? Can it be done in a different way?
This gives them a much better understanding of their clients and a market they’re trying to enter and, as a result, a much higher chance of success.
If you’re not familiar with what agile product development is, we’ve got you – check out our guide.
Inception
One of the most successful methods of getting the answers right before BRIDGeS was Inception. We’ve been running it since 2011 for all of our products and it skyrocketed the growth of companies such as Calendly, Brightbites, Mailtrap and others (see our Case Studies for more).
Back in the days, we were trying to find a way to quickly develop not only great products but the ones that deliver a lot of value to their users. We were invited to visit the folks behind Pivotal Labs who were well known for their product discovery techniques. They opened our eyes on the approach known as Inception and gave us first thoughts on how the process should be run. We’ve been enhancing the Inception concept ever since and these days it’s the first stage of any project we get involved in.
By the way, we are hiring. Check out our job openings.
Product Inception is a powerful tool for validating a product before it’s even launched. It’s incredibly useful because:
- It gets everyone on the same page. After only two days of an Inception meeting, development team knows precisely what needs to be built, who the potential users are and what problem we’re going to address. They also know how to mitigate the risks and which direction to head in.
- The team is ready to start from Day 1. Oftentimes, when you hire an external team, you need multiple days to brief everyone on existing infrastructure, code already written and ideas in a backlog. You also need to build a roadmap and get everyone familiar with it. After Inception, a production team just starts working and can report progress the following day already.
- You don’t waste time and other resources on building a product that you will likely pivot from anyway. While Inception won’t give you a recipe for another unicorn, it significantly boosts your chances of finding the right product/market fit.
- Finally, it’s a great way to integrate the development, product and founding teams together. After all, they will be working together for the upcoming months or even years and having a joint vision of a product and mutual understanding is often a key to success.
Tope Awotona
Calendly
Firstly, I have to say Railsware’s Inception is not an easy thing. But by doing it, I saved money, time and perfected my product vision. Let me explain how – this 2-day collaboration process is all about knowledge transfer, looking at the product from different angles, sorting out and prioritizing the details.
Part of this process is also bringing up potential risks: technical, business etc. Even though I had spent 6 months prior to the Inception conceiving what I thought was that perfect application, we still uncovered several risks during the Inception that led me to reconsider my initial product vision. That is the value of the Railsware Inception! Without the Inception, we would have wasted precious development resources on the wrong things. The Inception have helped avoid that waste of time and money.
We’ve explained how to put this mindset into action through lean product management in our blog, so feel free to check it out.
Agenda for Inception
Preparation
Before we start a Product Inception, we ask participants to gather everything that they have managed to build so far. This can include:
- Any live projects
- Wireframes and mockups
- Real-life scenarios
- Documentation
- Knowledge about competitors’ products
Basically – anything that will be relevant for us to understand the concept.
Once we set up the details, we share a detailed agenda to get everyone familiar with the process.
Check-in and introduction
Once all the participants gather and we all settle in a conference room, an Inceptor takes the floor and presents an agenda of the inception meeting. An Inceptor is a person from the Railsware team that will facilitate the meeting. Typically, it’s a product manager or a lead engineer. Their role is also to give direction to the whole session, connect the dots and extract all the knowledge from participants necessary for a positive outcome.
Aside from the Inceptor, typically at least one engineer and a designer joins in. On the participants’ end, we ask for a similar amount of people. Typically, it will be founders or C-level executives, product owners and subject matter experts.
An Inceptor sets the rules for this Inception meeting and we’re ready to move on. Our working space is split into two areas, referred simply as a left board and a right board. We’ll start off with the left one.
Demo
The first step is a presentation of the product. Participants cover their concept, step by step. We ask questions to clarify any doubts and once we’re on the same page, we continue to the next inception stage…
Customer Roles
In this part we’re going to work on defining the profiles of different customers that will interact with the product. Think of it as client personas that we describe in detail and then try to understand their point of view.
To analyze each role, we use IBR matrix with which we’ll write down:
- Issues that a certain role has
- Benefits that can be created for a given role
- Risks associated with each (both threats & opportunities)
We also write down any piece of domain knowledge that might seem relevant for either customer and put them on the left board. For example, an app for booking conference rooms would require a role of an office manager trying to find clients for his/her rooms. Domain knowledge for such a role could be “they know people book conference rooms typically 2-4 weeks in advance”.
Finally, we analyze the business itself with IBR matrix, domain knowledge and also business goals. We make sure the goals are SMART and add them to the board.
There might be a case when the issues determined are too serious to continue. In such cases, we won’t move on until we figure out how to address such obstacles. After all, they could derail the whole project later on and we would have wasted months of work.
Solution Ideas. Directions. Variations.
This is where we gather thoughts on a direction the solution should take. We already have the customer roles defined, know the risks associated with each. To add an additional context, we think of a direction that we should take. It can be launching native mobile app or app-wrappers which will render web views inside, or even building a web application which customers will use from their browsers.
Application Roles
Finally, we think about actual roles that will impact the product the most. In case of a food delivery company, these would be:
- Individual clients (consumers of food we deliver)
- Businesses that will be placing bulk orders
- Drivers who will be delivering orders
- Supervisor(s) of all drivers from within our company (aka admin)
- Operations manager(s) responsible for all processes (aka superadmin)
We, then, discuss and try to figure out which application roles are worth our focus. We can’t go with all of them, unfortunately. After all, we’re trying to build a minimum viable product (MVP) first so a certain focus is required.
We have lots of knowledge to share with you. Join Railsware team!
Epics and Features Breakdown
With the existing findings, we’re ready to move on to creating epics. Think of epics as large pieces of work that can be later broken down into smaller pieces. These can include “Android app v2” or “implementing a serverless approach”. But they can also involve completely different aspects such as user retention or partnerships.
Based on the roles we’ve analyzed in the previous step, we write down epics deemed important by anyone in the room and place them on the right board. We, then, go through each and check if they answer any of the issues we’ve determined before and placed on the left board. This process, known as story mapping, is absolutely essential. If an epic given doesn’t really address any of the issues from the left side, likely we shouldn’t be covering it in this session at all.
The more serious an issue, the higher an epic should land in the hierarchy. It happens when we examine our epics with MoSCoW method. This way, we rank each of the epics with either of the following four grades:
- Must’s – things that are absolutely critical for the product to work. They cannot be skipped or delayed.
- Should’s – epics that should be delivered at some point but are not prerequisites immediately
- Could’s – think of could’s as things that might be added to the project but only if they won’t distract us from more important goals
- Would’s (or Want’s) – nice-to-haves. Let’s skip them for now but have them in mind for future iterations.
We also ensure that the team has sufficient skills to deliver each of these epics. If not, likely such things should be deprioritized.
Action Plan
By now, we have the list of epics we want to work on and know which we should approach first. We already know which issues they address so we’re more than ready to plan more specific actions.
We break them down into specific tasks and run each through RASCI Responsibility Matrix. This means each task should have:
- Responsible – a person responsible for delivering a task
- Accountable (or Approver) – the one ultimately answerable for the delivery of a given task
- Support – people who can offer support with such a task
- Consulted – those whose opinion might be sought
- Informed – a person that should be informed about the progress of a task
Eddie Ross
TennisHub
TennisHub chose Railsware because of their full cycle product development experience and a key element is their Inception framework. I traveled to Kyiv for Inception and it was absolutely awesome. The level of detail and thoughtfulness that Railsware brings to the table is truly exceptional.
We discussed the intent of the application, market, business model, technical risks and, based on all of these factors, reorganized priorities to define precisely what features offer our customers the most value. I can say with certainty that Inception and the Railsware team are key reasons why TennisHub has been so successful.
Planning Poker
An optional but a very useful part of an Agile Inception is the so-called Planning Poker (aka Scrum Poker). Feature by feature, production team members toss cards on the table representing their own evaluation of time needed to ship a feature. The distribution of numbers is up to the team but frequently a Fibonacci sequence works best for such estimations. In such cases, Fibonacci numbers – 1, 2, 3, 5, 8, 13, 21 and so on – represent days, story points or other measurements. Participants who offer the highest and lowest values are invited to share their justifications. The team is then encouraged by an Inceptor to discuss and reach a common conclusion. This approach lets you easily reach reasonable estimations of a project while keeping everyone in the room engaged (and entertained ;-)).
Variations
The inception concept is great for building products but not only. We applied Inceptions in various cases! When started a new project within the company, when planned a summer retreat, when built a new office. Agile inception proved to be a very flexible and effective way of mitigating risks and validating concepts very quickly, whether you’re a product manager, a lead engineer or an office manager.
Typically, product Inceptions were held in either our Krakow or Kyiv office but it was also possible to arrange them at different locations. We would also run an Inception meeting remotely but only with teams that had done such a session in the past and knew the process. Remote sessions, in general, make communication more difficult and teams are less engaged. So if the budget allowed, we recommended an on-site visit.
Inception replay was also a thing! It was typically run for new team members to quickly onboard them to a project. The focus of the session was not a roadmap or epics. The agenda for Inception covered things like customer roles (IBR Matrix), company’s direction and application roles.
Finally, a re-inception was also an option. It’s basically a similar session held with the team months or even years later. Typically, it was held after clients gathered a significant portion of feedback from users or the team was headed into e.g. v2 of their product. In such cases, similar rules applied but the session might be cut a bit short as we already knew the basics.
How we developed Inception into BRIDGeS
Inception is a great tool that we had been using for quite a while. But like almost every tool that we use, be it a MoSCoW prioritization technique or RASCI chart, we started adding new elements and modifications to it until it evolved in a brand new approach. The framework we created – BRIDGeS, got all the best from Inception. At the same time, we made it more universal and precise to solve all sorts of problems in our organization, on our and clients’ projects, and in everyday life.
Find out how to run a BRIDGeS session and what advantages you and your organization can get when using it.
Summary
While there are many other product discovery techniques, Inception worked for us over and over again and became a starting point for our own product discovery framework. Time and time again, companies ship their long-anticipated products, only to find out they should have been building something completely different all this time. If spending a day or two can help you avoid such unpleasant surprises, we strongly believe it’s worth it.
This covers the product discovery process at Railsware. Still, we are constantly trying to improve it, so if you practice Inception or BRIDGeS in the future, we would definitely love to hear your feedback.