You Don’t Need Code, You Need to Test Hypotheses

Clients often come to Marmelab with a development request and a solution already in mind. But in reality, what they truly need is not code, it’s to validate hypotheses.

We’ve sometimes started projects directly from client specifications, mockups, or backlogs, without prior preparation on our side. Each time, this approach has failed, proving that appropriation is essential. Yet, preparation is often perceived by clients as a waste of time, because they already know the context.

We know that an innovation project’s success depends on how quickly we can build and test the most critical hypotheses. That’s why we’ve designed a very quick Design Sprint (also known as “Sprint 0”) that streamlines the discovery phase and sets the project up for success in just two weeks.

What Customers Get from Design Sprint

The main purpose of the Design Sprint is to identify and prioritize the key features that will allow us to test the most critical hypotheses as quickly as possible. By focusing on these features, we can validate assumptions early and avoid wasting time and resources on unnecessary development.

So the main deliverable of a design sprint is a Feature Map and the Sprint Backlog for the first development sprint. Our customers often come with many features in mind, so my job is to prioritize them, to challenge the solutions proposed by the customer when they don’t align with the objectives, and to settle on a Definition of Done for each feature.

I also produce a Developer Handbook, a document capturing all key information and decisions made during the sprint as well. This includes user personas, pain points, objectives, competitive analysis, solution scope, prioritized features, risks, and constraints.

The Design Sprint also establishes the Software Architecture’s main guidelines, ensuring that developers can start coding without spending time on design decisions.

We know that every hour developers spend not coding is wasted money from the client’s perspective. That’s why I, as a facilitator, prepare everything in advance so developers can start the project in record time: after just a single kick-off morning.

How a Design Sprint Works

A Design Sprint usually takes five days spread over a two weeks period, during which the facilitator prepares, leads workshops, and documents all information and decisions.

The sprint is divided into two main phases: “Define the Problem” and “Find the Solution.”

In the Define the Problem workshops, stakeholders align around a shared vision while the facilitator gains a deep understanding of the context, user personas, pain points, objectives, and competitors. This phase usually lasts for one day.

Even if the client team already feels aligned, this phase is essential to ensure the facilitator reaches the same level of understanding as the client and user. Ideally, we get to meet a few end users to better understand their pain points.

The rest of the Design Sprint consists of Find the Solution workshops, where we focus on shaping a concrete path forward: defining the solution scope, prioritizing key features, and assessing risks and environmental constraints. The outcomes form the foundation for the first development sprints.

For a detailed look at how decisions are made within each workshop, I recommend reading the article The Agile Setup: How Marmelab Bootstraps Projects In 2 Weeks, which explains our process step by step.

By fully understanding the project context, the facilitator can propose solutions, advise and support both clients and end-users. The final call, however, always belongs to the client. That’s why, from the outset, it’s crucial to designate a clear decision-maker, a Product Owner, someone who can resolve disputes and make final decisions when stakeholders disagree.

And After the Design Sprint?

After the design sprint, the client is free to have Marmelab develop the solution or to do so themselves using the developer handbook.

If the client chooses to have the solution developed by Marmelab, we start an iterative development phase split into two-week cycles. During each Development Sprint, developers implement the features prioritized by the Product Owner and prepared during the previous sprint.

We noticed that the success of the project relies heavily on clients and users’ involvement and timely feedback. While we can adapt at any stage, the earlier feedback arrives, the more meaningful the improvements we can make. That’s why the client’s role is crucial: regularly testing new features and sharing feedback as quickly as possible.

Meanwhile, the facilitator continues to organize workshops with the client and users to prepare upcoming developments. Preparation always stays one step ahead: the Design Sprint defines the features for the first development sprint, while the first sprint sets the groundwork for the second, and so on. During implementation, the facilitators spends two days working on the project spread over a week.

During development, it’s easy to get carried away by new ideas and assume every innovation must be implemented. However, time is limited, and not everything is feasible. To make thoughtful decisions, we regularly step back and revisit the objectives and key assumptions established during the Design Sprint.

This approach makes it easy to adjust along the way, or even pivot entirely, if testing shows that the initial solution from the Design Sprint isn’t the right fit. It’s all about maintaining the right balance between direction and flexibility.

Conclusion

We have developed a project initialization method based on Lean Startup principles. It has evolved over the years to become more adaptable to various customer contexts, allowing projects to move quickly, efficiently, and with purpose. By aligning stakeholders, prioritizing features, and preparing ahead, we minimize wasted effort and maximize the value of each development hour.

Ultimately, the Design Sprint converts uncertainties into insight, problems into hypotheses and the ideas into action. It’s the most effective way to ensure that what we build truly meets the needs of users and drives meaningful outcomes for our clients.