Product Discovery Workshop: Not just gathering requirements, but validating a business, collaboratively
What do we do?
At Elemental Concept, we build software for start-ups to multi-national corporations. These days, multi-nationals are trying to transform their own business models before a rapidly moving start-up takes their customers, so there is an overall need across all types of organisations to get the right solutions to market quickly. The methods I have outlined in this article have worked well for both start-ups and large organisations.
Through ideation, requirements gathering and building systems, we adopt lean methods. In other words, we are not wasteful – we strive not to waste client’s time or money. We encourage failing fast and knowing when to pivot whilst validating our learning with cheap experiments.
This article summarises our continually evolving requirements gathering approach, which we call PRODUCT DISCOVERY. This is a workshop, which lasts between 1-5 days. During the workshop, we employ business, technology and design techniques to ensure a strong understanding of the client’s needs.
This will be a useful read for anyone who needs to effectively gather requirements for any type of project and is into lean and design techniques. Throughout my career, I have initiated, managed and been the client for many projects and this is the most effective, enjoyable and least wasteful process I have ever used.
The birth of Agile
For some context, I’ll give a brief explanation of why Agile software development methods emerged. Over the past few decades, there have been a plethora of miserable IT project failures, many of them managed using traditional Waterfall methods (think detailed requirements gathering up front with monolithic business requirements documents).
The pace of change in today’s world of business and technology transformation lends itself to a less rigid methodology that welcomes changing requirements through the project life-cycle. History has shown that the larger and more complex the project, the riskier it is to use Waterfall project management.
In 2013, the calamitous release of the Healthcare.gov website (development costs in excess of $174m) exposed one of the most epic Waterfall fails leading to the emergence and bedding in of Agile methods.
Prepare for the Workshop
We prepare by researching the relevant business environment, market trends and dominant competitors, which help us to validate the business idea ahead of the workshop. By the time the customer arrives for the workshop, the wall of our office is covered with material to facilitate and provoke discussion. We’ll encourage workshop participants not to stay seated at the table writing into their notebooks. Instead, if they have something to write down, they write it on a post-it and stick it on the wall – everyone can see it when they want and there is a shared understanding created.
Several internal staff participate in the workshop to bring a mix of skills and experience creating different perspectives in the room. We have found that this helps to generate more rounded ideas – the best ideas and challenges can come from anyone, senior or junior.
Do the Workshop
Assessing the Business model
We start by assessing the client’s business model. To do this, we use a slightly modified business model canvas, which was introduced by Alexander Osterwalder in 2008. The canvas is a tool that enables the people in the room to understand the big picture of a business model. We stick post-its into each canvas section to highlight the most important business model characteristics. The canvas becomes a tangible and persistent object to which we reference for the remainder of the workshop and during the software build too.
We begin with the fundamental reason for creating a business by defining the problem that needs to be solved for a customer segment. To illustrate, an example problem for Dropbox might have been: “It’s time-consuming and difficult to access and edit files across multiple devices”. The unique value proposition (UVP) describes the differentiator and could be a marketing tagline for your business, e.g., “data is securely backed up/sync’d automatically to multiple devices with no human intervention”. Other examples of the UVP might be a business model that is heavily customised to one customer type, offers services at low prices or performs a function quicker than the competition. The metrics section highlights a few actionable metrics that will be used to measure success. The following populated canvas is an example from a recent workshop.
The Magic of Story Boards
Once the canvas has been filled in, we move onto storyboarding. Storyboarding is about imagining a future where your product or service exists and then telling detailed stories about how people will use it. This technique helps to understand exactly how the software will work and is much better than an abstract description. Story boarding takes place in two distinct phases; persona mapping and user journeys.
Persona Mapping
To understand the end users of an application, we map out their characteristics using the ‘empathy map’ tool. We populate all the areas shown on the empathy map and end up with a very clear picture of who this person is, what they think, what their goals are, their frustrations, etc.
We usually try to identify someone known to the client to bring more clarity to the stories for the user journey section.
User Journeys
A User Journey is not a generalisation of something happening; it’s very specific. We detail how the future state product or service will be used by the personas, generating specific scenarios using the Job Story notation.
This is an example story board below. Whilst such specific user journey details in themselves are not relevant, during such storytelling we have again and again seen that valuable insights and details get revealed that are otherwise lost in generalisations.
To extract more clarity from storyboarding, we draw any screens on a flip-chart – it’s quite difficult to nail down specifically what information you need on a screen. Again, this moves us away from generalisations and abstractions.
Story Mapping
In the next section of the workshop, we build the story map, derived from the user journeys. The story map arranges user stories into a model to help understand the functionality of the application, identify new requirements, and effectively plan releases that deliver value to users and the business.
We arrange all the features and functions in columns with the high level functional area at the top of each column. Now, the client prioritises each column, so that the most important stories are at the top of each column decreasing in importance as you go down.
The Minimum Viable Product (MVP)
Airbnb, Snapchat, Uber, Spotify, Dropbox and the other unicorns out there all started with a good business concept that was validated in its simplest form, the minimum viable product (MVP). This was then pushed in to the mega product that you know today.
We always strive to build the MVP, which is used as a tool to collect user feedback. That feedback is used to improve the product and validate the concept. Based on the feedback, the client can rapidly pivot, persevere and scale, or dismiss the project altogether. Once the story map has been prioritised, we identify the features for the MVP, endeavouring to keep this as small as possible, so it’s kept quick and simple.
Prototyping
At this point, instead of proceeding with the build, we like to add a further validation step. We build a prototype to make sure that potential end users want to use this product and the user flow is simple and intuitive. The prototype is high fidelity, so if it’s a mobile app, the prototype looks like the real thing; it runs on a phone, it’s interactive, but no software has been developed. The data is all faked rather than being delivered and processed via a web server or API, so it’s very quick to build (~1 week).
Once the prototype is built, we run a user interview session, where a UX designer observes and interviews users whilst they use the prototype. The feedback is used to refine the prototype and now, we are ready to start the Agile development phase.
Why we love it
Every time we have run this workshop, we see the client go on a journey. They understandably arrive with pre-defined ideas and it can be hard to let these go. Through this process, we encourage leaving preconceptions behind to generate fresh ideas. The client stakeholders walk in usually knowing what they want, but they walk out knowing what they need, as some of the features that the customer wants are usually unnecessary for the MVP, which is a learning tool. The workshop gives ownership to the people in the room – we want to deliver the product and we believe in it.
Please contact us at Elemental Concept ([email protected]) if you would like to know more about our product discovery or indeed if you would like to try it out for yourselves.
