How to start a product from scratch
<TL;DR;>
This a REX (Return on EXperience) overview on how we started KYC (Know Your Customer) as a product. If you’re only interested in the takeaways, go directly to the last paragraph
</TL;DR>
Here in our company, we had to ramp up on different products when we created the new subsidiary. I’d like to share how it happened for the KYC product, what were our different pitfalls/rituals/workshops and what we’d keep and change if we were to open a new product again. I think this is a journey that can be different for any team/product, but the milestones could be shared across different teams
Tips : In the following parts we’ll be mentioning a lot the word “Workshop”. What workshop means for us? It is a team exercise where it is allowed to discuss and challenge everything as a team. Usually, it starts with a question, then people are given 5–8 min to brainstorm alone and write down their ideas on Post-its, and then debate them while trying to converge on an output.
The Idea (The Conception of the Product)
As any product starts, someone had an idea. For us, the idea was coming from two different directions. First, it was a legal requirement to enable our wallet solution transfer between two accounts. Secondly, it was an idea from PJ/Charles to sell as a product with credit score (I won’t enter into the details here)
Now, as it is often the case with ideas, people had an idea of the solution “Let’s do KYC! It’s an international standard, let’s implement it! ”. So we started to dig into it, asking the SG team what was already in place, what was their need/vision of it..
The Framing (The Birth of the Product)
So here we had a bunch of requirements, a few people to talk to and an entire product team(3 developers and a PO) ready to dig into this adventure! We all agreed to start to frame it to have a clearer vision of what to do, what to start, etc… Here are all the workshops that happened, and after the one or two that were missing.
The framing: a series of workshops designed to help you have a 360-degree vision of the landscape of your future product
- Vision
- Lean Canvas
- Team
- Persona
- Storymap
- Architecture
- Methodo
- Roadmap
- Backlog
Vision workshop:
The first workshop of a product is always hard “Where do I start?”. Well, we started with the following one. The goal was to brainstorm as a team and converge on different topics for the 5 following themes :
- Who are our users?
- What are the needs of our users?
- What are the challenges for OnlinePajak?
- What is our added value proposition?
- What are our Success/Failure criteria as a team for this product?
It took us more than 2 hours to converge with ideas on these matters, even though we were helped by an external facilitator (Tech Lead from the other product team) to keep us focused. My2cents on this workshop is that often, the harder the conversation is, the better it is. Indeed conversation needs to happen and the more the ideas get challenged the more the team as a whole converge with the same vision. If you’re lucky at the end of this workshop you can even have your product manifesto, a sentence summing up the why, how, what and for who of your product. It wasn’t the case for us. Once this was over we tried to digitise it to make sure we kept track of these 2 hours of teamwork.
Team workshop:
Before going any further, we decided to see how we would organise ourselves as a team :
- What is the role of each participant?
- What responsibilities for which role?
- Who does what?
- What are the people/role that we define as “part of the internal team” and part of “the overall team”?
- Who are the people external to the internal team that we need to talk to?
This workshop is short (~30 min) and was nice to be able to exchange and share how we saw the roles of each other. It is usually a good moment to make sure that everyone expects the same behaviour from each other, and that there is no mismatch. As usual, once it was over we digitised it to make sure we wouldn’t lose anything.
Last but not least, you should pick a fun team name!
The Personas workshop :
Now that we had a rough vision of what our product was about, and how to organise ourselves, let’s discuss who our different users would be. Usually while you dig a bit more into your users, you find yourself challenging the vision you established earlier. It is perfectly fine. We used the following model to try to describe our different users:
- A name
- Her background story
- The problems she has right now
- The frustrations she has
- A quote to sum it up
- Rough age
- Job title
- 4 key things that define her
- What she would do if she has a magic wand right now
See below on how it looks
You should repeat the exercise as many times as you find a profile that is really different from the ones you already have.
Once you’ve created enough of them, the goal is to be able to :
- Categorize them as Primary Persona, or Secondary Personas
- See if you can group them by needs so that some functionalities would fit different personas within the same group
Doing so will probably challenge your vision but also detail it a bit more, as it is easier for a human to visualise a product with more concrete examples than just ideas.
Same old, same old, digitise everything afterwards to avoid to lose track afterwards!
Challenge your vision with your stakeholders
At this point, we shared the beginning of the vision that we had with the different stakeholders to make sure that we were aligned on what we discovered and the overall idea of the product. Lucky us, everyone was aligned.
How did we do it? Well, our idea was to create a fake Product Release note, trying to present the main features that we would focus on in the next few weeks/months. It was the first time I was experimenting such thing, and the result (use a Product Release Note as a way to challenge your vision) was better than expected
The storymap Workshop :
Once we’ve reached that point, we considered that we had enough knowledge on what was surrounding the product to create our first version of the storymap. We decided to facilitate it on an event-based roadmap, ie start with an event to see the different flows that this event was either creating or following. That gave us a first version of what were the different steps in our product, and possible releases based on that. It also gave us the limits of where we wanted to stop thinking because it was outside of the product itself.
The Methodology Workshop
Now you know the first EPICs that you want to develop, let’s take an hour to discuss on how to organise ourselves to work as a team ! During this workshop, the goal is to define the first iteration of how you want to work as a team.
This includes the following discussions :
- Board? Columns/Step in the board?
- Kanban/Scrum/Scrumban/Whatever?
- Rituals? Frequency?
- Definition of Done (DoD)
- Tools that you want to use as a team
- Definition of a story
- Etc..
The goal here is to discuss, agree and align on how to work as a product team, and to be able to refer to it while developing the product and update it if needed
The architecture workshop
This workshop is for the dev team to discuss overall architecture and technical dependencies identified before the start. Nonetheless, the presence of the PO is crucial, as he/she is here to represent the “functional” during this workshop
The roadmap Workshop
Now that we knew what to do, how and why, let’s take a bit of time to see how we can deliver/prioritise the features. The goal of this workshop is to identify the different “Streams” or “EPICs” that you have in your product and regroup the different functionalities in it to be able to deliver a rough view of the different areas of focus for the next few weeks/ months. A roadmap should never be a “fixed” thing and should be updated as you deliver, and prioritised regularly. The key is to be able to visualise what are going to be the different objectives/ subjects for the team to work on simultaneously at a given point in time
Optional: The Lean Canvas Workshop
The goal of this workshop is simple to understand but hard to do. You need to fill the Lean Canvas with input that is coherent with each other. The hard part is that this document has been designed on purpose to link together all the parts that intervene in the life of a product.
For KYC, we chose not to do it because it was not making a lot of sense (Legal/Technical requirement, no sales) but it was quite useful on another product
Key takeaways when starting a product
The framing: a series of workshops designed to help you have a 360-degree vision of the area of your future product.
The different workshop can be different in length and content based on the product. But you will probably find the 4 following steps :
Divergence of the problem, i.e. explore what is really the implications of the problem that we’re trying to solve
Convergence of the problem, i.e. converge as a team to the one problem that we will try to solve with the product
Divergence of the solution, i.e. explore the domain of the solutions to answer that specific problem
Convergence of the solution, i.e. converge on one solution to implement and then iterate on it
Summary: the workshops
While continuously learning more about the domain/business/technical side of the product.
It usually takes 2 to 4 weeks to complete a framing and have a first real 360 degrees vision on a product
