Product Discovery: Highlights from my Agile Software Development book

At 10Pines we build software for several types of customers; from large corporations, such as Claro and Burger King, that want to develop new products or expand the functionality of existing tools, to newborn businesses that seek to build an initial version of a product. Even when the needs, the size of the problem and obviously the budget differ, we always begin our developments by a stage that we call Product Discovery, where we meet with the specialists in the business, our clients, to create a shared vision.

We facilitate this stage through a series of workshops that we develop in collaboration with all stakeholders (business users, developers, testers, UX specialists, designers, etc). These workshops can last from 4 hours to a few days (the amount of time depends on how well the problem is understood and how aligned the stakeholders are). The synergy created by the combination of all these diverse minds enriches the result. The same people that participate in the discovery, is also involved later in the development of the product, thus minimizing waste (hand-offs).

A good Product Discovery allows us to create a shared vision, aligns the team and stakeholders and sets the basis of a relationship based on trust and collaboration.

What do we want to "discover"?

Let’s see what we are trying to discover:

Why: Who are the people having problems or needs? Which are such needs? What is the value they will receive?

How: are the most important flows of value of the users through the product? What are the most important features the product will have?

Priorities: Which are the essential features? What is the minimum experiment (Minimum Viable Product) that will allow us to test our value hypothesis?

Risks: What could go wrong (both from the business and technical perspective)?

Those are the most important things we need to discover at this phase. Sometimes, we dig further on:

Business Model: How do they plan to make money? What is the product differential? What are the processes that this tool will optimize?

Magnitude: How big is the MVP?

Architecture: What are the most important components of the product? Which external systems do we need to interact with?

People: Do we know the team? Do we know the stakeholders? Which of the teams do we need to interact with?

Product Discovery Workshops

Have you ever received a ‘Requirements Document’ from which you need to understand why the product is needed and what do they want to build? It’s difficult, isn’t it? At 10pines, we prefer to invite the people that have needs/problems, the people that have an idea to solve them, and a bunch of experts that know about technology, UX, etc. to a series of Workshops that we facilitate.
This way we've found out there's a huge difference when we hear what is happening first hand. We can empathize and deeply understand the problems. We can grasp how end users feel about them. We can design solutions and discuss them. Stakeholders can agree on them. Having a diverse public allows us to detect hidden risks and have diverse ideas. And we get to know personally all the stakeholders! This becomes really important when we work in big corporations where, most probably, you will have to interact with many areas and departments..

Tools

We use a set of tools which, though light and intuitive, still enable the collaboration of all participants. These tools are tactile (stickies or cards), enabling a very intense way of collaborating. Johana Rothman says about this: ‘starting with tactile tools (stickies or cards) helps people create a shared understanding of the work under discussion.’. When I see people talking, writing post-its, moving them, etc. I can tell it’s true.

Understanding the problem and the value we are going to add

The first thing we must understand are the problems and needs of a user (or group of users). We use a couple of tools that allow us to talk about them.
The first one is called Elevator Pitch. The idea is very simple. Put the wording of your business idea into a set of sentences that allow you to explain such idea to a potential investor in case you ran into him/her in the elevator. In a few floors, you need to sum up the key concepts: who are you aiming to, what are their problems/needs, what is the value they will get and what is the differential (compared to products that already exist). We put a flipchart with the following categories, to fill up by all participants:

For (Key Customers)

Who (Needs or Problems)

The (Product Name)

Is a (Type of application or vertical)

That (Key benefits or most important reasons why you would buy it)

Unlike (Main competitor)

Our Product (Differential)

Another tool that we use is the Lean Canvas, which is an adaptation of the Business Model Canvas (created by Alex Osterwald), made by Ash Maurya and popularized by Eric Ries through his Lean Startups Methodology.

This tool goes a step further as you need to state how you are going to reach your clients, measure success, earn money and what the cost structure is. There are a few digital tools for this like https://leanstack.com/ or https://canvanizer.com/

Of course you can customize the sections that you want to include in the Canvas. For example, with Gisela Decuzzi, in a Workshop that we facilitated a couple of years ago, we took out the channels/revenue streams & cost structure to instead focus on the problem/solution and unique value proposition. Jorge Silva, a colleague at 10Pines, made another customization which he called ‘enterprise lean canvas’ better suited for corporate projects.

Understanding how we are going to achieve it

One of the things we like to do inside the workshops is imagining a few of the most important flows of value (business processes) and map them using a tool called User Story Mapping. This allows us to visualize the most important activities of users in a timeline and a breakdown of the tasks involved in each of the activities.

We can also talk about priorities. If there were a few ways to achieve a certain business process, we can discuss and decide which ones are more important, and plasmate those decisions in the map, placing the most important ones on top. We can also decide which one of those should be included in the Minimum Viable Product.

Did I say I love this tool? Well, yes I do. I love how I can explain it in just a couple of minutes and start building shared understanding with the collaboration of all participants immediately. I love how we can visualize and walk through our most important user activity flows. I love how we can arrange and rearrange post-its so easily, without any friction. I love the conversations held in front of the map: telling stories and giving them a framework is such a visual combination!

Understanding our users

One of the things I’ve learned in these past few years is how important it is to understand ‘our’ users. Understand their context, how they perform their activities currently, how they feel about them and problems they are currently having.

Our UX experts (and a few UX friends) have a few tools that we use in the Workshops. For example, one called ‘Personas’ with which we can ‘represent’ the most important traits of our users, or ‘Customer Journey Map’ which is very similar to the User Story Map, but focusing more on the emotional aspect, or empathy maps which helps understanding people’s feelings and emotions as well.

Understanding risks

What are the biggest risks? What can go wrong? Which are the things we understand the least? It is good to identify and address all these aspects as soon as possible. In case of a problem/uncertainty, it can even make sense to solve it before investing any money, right? To discuss these things, we use an activity called ‘What takes your sleep away’. The activity is brief (it can be done in 15/20 minutes) and allows all participants to make these fears explicit, debating the potential impact each could have.

First, each participant thinks for 5’ about their fears and writes them on a post-it. Then everyone paste all post-its in a flipchart and categorize them in a matrix, according to their impact & probability. Risks with high impact/probability should be addressed first.

Lean Sales Up

So, when should the Product Discovery Workshops be done? I think it has to be the first activity in any project and, yes, this includes the sales phase. As Jorge Silva stated in his Lean Sales Up presentation, it is great to do it before selling the project to understand all these things previous to starting a relationship. This way, we avoid over-estimation (or under-estimation, resulting in unreal dates), we take time to discuss value and feasibility, we design together and we align. More importantly, there are no intermediaries. It’s the development team and clients discussing these important matters and avoiding hands-off or the possibility of shallow promises.

Where can I learn more?

Sometimes people ask me where to learn more from Product Discovery. My answer is: ‘There is so much to learn!’. I really enjoyed Paulo Caroli’s Lean Inception book and Jeff Patton’s User Story Mapping (which is much more than just an explanation of the tool!). I attended @soyezequiel Design Thinking Workshop and really enjoyed it. I didn’t attend the Product Discovery course that @rcolusso gives, but I helped him facilitate the workshops he designed for developers4good. Doing by learning is the best way, and you have the possibility of collaborating to this great social hackathon while learning from an expert.  I also have a couple of books in my bucket list: Lean UX: Designing great teams with Agile Teams & Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days.

Conclusions

We always start our projects with a phase called Product Discovery, that consists of a a series of Workshops in which a diverse crowd of business & technical people participates. We use a set of light tools that help us facilitate these meetings. Doing a good Product Discovery is the best way of starting any development project. It allows all stakeholders to build shared understanding, it aligns them and it builds the basis of a relationship based on collaboration.