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.
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:
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.
One of the most successful methods of getting the answers right is 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.
Product Inception is a powerful tool for validating a product before it’s even launched. We love it so much because:
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.
Agenda for Inception
Before we start a Product Inception, we ask participants to gather everything that they have managed to build so far. This can include:
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.
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…
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:
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.
Finally, we think about actual roles that will impact the product the most. In case of a food delivery company, these would be:
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.
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:
We also ensure that the team has sufficient skills to deliver each of these epics. If not, likely such things should be deprioritized.
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:
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.
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 ;-)).
The inception concept is great for building products but not only. We do Inceptions all the time! When starting a new project within the company, when planning a summer retreat, when building a new office. Agile inception has proven 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 are held in either our Krakow or Kyiv office but it’s also possible to arrange them at different locations. While we don’t recommend it, it’s possible to run an Inception meeting remotely but only with teams that have done such a session in the past and know the process. Remote sessions, in general, make communication more difficult and teams are less engaged. So if the budget allows, we recommend an on-site visit.
Inception replay is also a thing! It’s typically run for new team members to quickly onboard them to a project. The focus of the session is not a roadmap or epics. The agenda for Inception covers things like customer roles (IBR Matrix), company’s direction and application roles.
Finally, a re-inception is possible but is also optional. It’s basically a similar session held with the team months or even years later. Typically, it’s held after clients gathered a significant portion of feedback from users or the team is headed into e.g. v2 of their product. In such cases, similar rules apply but the session might be cut a bit short as we already know the basics.
While there are many other product discovery techniques, this particular process worked for us over and over again and we’re convinced it really makes a difference. 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 Inception process at Railsware, which is already in its 8th year after implementation, after hundreds of Inceptions and dozens of successful product launches. We are constantly trying to improve the process, so if you participate in one of the sessions in the future, we would definitely love to hear your feedback.