Product Discovery Workshops: a lean approach to software requirements gathering
What this article covers: This article explains Product Discovery – our structured workshop methodology for gathering software requirements before development begins. It covers how the process works in practice, why lean and Agile principles underpin it, and what clients typically learn about their own product by going through it.
Who it’s for: Product managers, founders, and technology leaders who are preparing to commission a software build and want to reduce the risk of building the wrong thing, or building the right thing badly.
What you’ll learn
- Why traditional requirements gathering (Waterfall) consistently fails on complex software projects, and what the research shows about the cost of getting this wrong
- How a Product Discovery workshop is structured, from business model assessment and persona mapping through to story mapping and MVP definition
- Why prototyping before development — not after — is one of the most cost-effective risk reduction strategies available to any software project
- What is the difference between what a client wants at the start of the process and what they actually need by the end of it
- How Elemental Concept runs Product Discovery in practice, and what you can expect if you commission one
Skip to glossary of key product discovery terms
What do we do?
At Elemental Concept, we build software for start-ups to multi-national corporations (amongst other things…). 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 system development, we adopt lean methods. In other words, we are not wasteful – we strive not to waste the 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 and 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.
Why agile methods replaced waterfall (and why it matters for your project)
The birth of Agile
For context, I’ll briefly explain 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 business and technology landscape lends itself to a less rigid methodology that accommodates changing requirements throughout 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.
How we prepare: research before the workshop begins
We prepare by researching the relevant business environment, market trends and dominant competitors, which helps 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 in 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 members participate in the workshop, bringing a mix of skills and experience and creating diverse 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.
What happens in a typical product discovery workshop?
Business model assessment: starting with the big picture
We start by assessing the client’s business model. To do this, we use a slightly modified business model canvas introduced by Alexander Osterwalder in 2008. The canvas is a tool that enables 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, persistent object to which we refer for the remainder of the workshop and during the software build as well.
We begin with the fundamental reason for creating a business: defining the problem 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 more quickly 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 storyboards
Once the canvas has been filled in, we move on to 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. Storyboarding takes place in two distinct phases: persona mapping and user journeys.
Persona mapping
To understand the application’s end users, we map 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, their goals, frustrations, etc.
We usually try to identify someone known to the client to provide more clarity to the user journey stories.
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 storyboard below. Whilst such specific user journey details are not, in themselves, relevant, during such storytelling, we have repeatedly seen valuable insights and details emerge that would otherwise be 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: turning user journeys into a product roadmap
In the next section of the workshop, we build the story map, derived from the user journeys. The story map organises user stories into a model to help understand the application’s functionality, identify new requirements, and 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)
What is an MVP and why do we build the smallest useful thing first?
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 an MVP that serves 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 it as small as possible so it’s quick and simple.
Prototyping and user testing before a single line of code
At this point, instead of proceeding with the build, we would like to add an additional 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, it looks like the real thing: it runs on a phone and’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 in which a UX designer observes and interviews users whilst they use the prototype. The feedback is being used to refine the prototype, and we are now ready to start the Agile development phase.
Why we love it and why product discovery works
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 you to leave preconceptions behind to generate fresh ideas. The client stakeholders usually walk in knowing what they want, but they walk out knowing what they need, because some of the features the customer wants are 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 if you would like to know more about our product discovery or, indeed, if you would like to try it out for yourselves.
Glossary of key product discovery terms
Click to expand and view the defininition.
Product Discovery:
A structured pre-development workshop that brings together business, technology, and design thinking to establish what a product actually needs to do, and why, before any code is written. At Elemental Concept, Product Discovery typically runs over one to five days and produces a validated, prioritised understanding of the problem being solved, the users being served, and the minimum viable scope required to test the concept in the real world.
Lean methods:
An approach to product development borrowed from manufacturing that treats wasted time, effort, and money as the primary risks to manage. In a software context, lean means validating assumptions with the cheapest possible experiment before committing to a build, welcoming changes in direction when the evidence supports them, and avoiding the trap of building extensively before testing whether the thing being built is actually wanted.
Prototype:
A high-fidelity simulation of a product, interactive and realistic in appearance, but built without functional code or a live back-end. At Elemental Concept, prototypes are typically completed in around a week and used in structured user interview sessions before development begins. The purpose is to test whether real users can navigate the product intuitively and whether the concept resonates, catching fundamental design problems at a fraction of the cost of fixing them post-build.
Agile
A software development methodology built around short, iterative cycles of work rather than long, fixed plans. Agile emerged as a direct response to the failure rate of Waterfall projects, particularly large, complex builds where requirements changed faster than monolithic plans could accommodate. The core principle is that working software delivered incrementally, with regular feedback loops, produces better outcomes than a single large release built to a specification written months or years earlier.
Business Model Canvas:
A single-page strategic framework, introduced by Alexander Osterwalder in 2008, that maps the key components of a business model — including the problem being solved, the value proposition, the customer segment, the revenue model, and the key metrics that define success. Elemental Concept uses a modified version of the canvas at the start of every Product Discovery workshop to establish a shared understanding of the commercial context before moving into product design.
Empathy map:
A tool used during persona mapping to build a detailed, human picture of who will actually use a product. Rather than defining users by demographic data alone, an empathy map captures what a person thinks, feels, says, does, and struggles with in the context relevant to the product being designed. The result is a more honest and useful design brief than a generic user profile.
User journey:
A specific, scenario-based description of how a real person will interact with a product to accomplish a goal. Critically, a user journey is not a generalisation; it is a concrete narrative that follows a named persona through a particular situation, step by step. Elemental Concept uses Job Story notation to structure these journeys, which forces specificity and consistently surfaces requirements that abstract descriptions miss
Story mapping
A technique for organising user stories, the individual tasks and interactions that make up a product, into a visual map that shows both the breadth of functionality and its relative priority. The map is arranged so that the most essential features sit at the top of each column, with lower-priority enhancements below. This makes it possible to draw a line across the map that defines the Minimum Viable Product: everything above the line ships first, everything below it waits.
Minimum Viable Product (MVP):
The smallest version of a product that delivers enough value to real users to generate meaningful feedback. The MVP is not a rough draft or a cost-cutting compromise — it is a deliberate learning tool. The goal is to validate the core assumption of a product concept with the least possible investment before committing to a full build.
Prototype:
A high-fidelity simulation of a product, interactive and realistic in appearance, but built without functional code or a live back-end. At Elemental Concept, prototypes are typically completed in around a week and used in structured user interview sessions before development begins. The purpose is to test whether real users can navigate the product intuitively and whether the concept resonates, catching fundamental design problems at a fraction of the cost of fixing them post-build.
Job Story notation:
A framework for writing user requirements that focuses on the situation a user is in, the motivation driving them, and the outcome they want to achieve. The structure – When [situation], I want to [motivation], so I can [expected outcome] – forces product teams to think from the user’s perspective rather than the system’s, and consistently produces more actionable requirements than feature lists or abstract use cases.
