How does Discovery Add Value?
If you’re a prospective client of Lab Zero, then you have a software solution in mind. It’s axiomatic: if you didn’t have a solution in mind, you would not have the approval to solicit proposals from top-shelf development agencies like Lab Zero, and we would not be talking to you. But, since we’re talking, we know that you’ve already encountered pain, or opportunity, and you have started to think how software could solve that problem or meet that opportunity. In short, if you are talking to us, then you have a software solution in your head.
So why is it that, when we send you our proposal, it contains a phase called ‘Discovery’? Haven’t you already discovered? Haven’t you examined your problem and outlined a solution centered on a critical insight? You probably have.
Discovery neutralizes Solution Bias
Solution bias (falling in love with a specific solution) isn’t just your problem: it’s a problem that affects entire organizations. Harvard Business Review and MIT’s Sloan School of Management have a lot to say about this.
The reason we include Discovery in most proposals is simple: we’re out to deliver value. And although your outlined solution usually leverages a critical insight, our fresh eyes and process are going to give legs to that critical insight and deliver more value.
Discovery makes a Breakthrough Possible
One of our clients described their problem to us. An aging website was starting to fail both from a maintainability and reliability perspective. They described the replacement site to us so perfectly, they sold us on the idea of starting to build it immediately. They had modeled a compelling user experience with care and precision. They had figured out how the app would be architected so that it could survive peak loads with high performance. They had even figured out a migration strategy that would get users seamlessly from the old site to the new site.
There was just one thing standing in the way: three weeks of Lab Zero ‘Discovery’. We were committed to kicking the tires of the concept with a few real users. It would be three weeks before developers were available to start. So in that time our design-and-product tag team hit the bricks.
What happened next was unexpected. The second user we talked to described their daily routine as “I check my inbox for status updates from Systems X, Y and Z. Then I log into your system, go to the ‘Updates’ page, and under the third tab I check for anything red."
Wheels started spinning. They were getting email updates for most of the daily decisions they needed to make; they were starting their day in their inbox, getting context for the work. We started asking questions about the kind of information they got from the system, how frequently it changed, how they used it. Our Discovery ended up taking four weeks. But at the end of it we had outlined an alternative solution that involved a single daily email in place of the new site.
The complexity and time to build and launch were cut by 70%. The migration became easy. And a new bridge of trust appeared between the community of users and the delivery team. By thoughtful listening in Discovery, we helped our client deliver the value of the app with the ease of an email.
This kind of breakthrough doesn’t happen every time. But it happens often enough that, in addition to other benefits, we always achieve a better result starting with Discovery.
But Can’t We Just Skip Discovery?
We encounter a variety of client reasons why we should ‘skip’ Discovery during a project.
Time pressure. We just need to solve this problem fast, and we have a solution so let’s just build it.
Favorite tools. We’re really good at Tableau; and it turns out that most problems can be solved with a new Tableau dashboard.
‘Sold’ Solution. We’d love to take the time to document our problem with you, and to explore different solutions, but our exec team has already been sold on this solution, and now we just need to deliver it.
In each of these cases, we find that it’s worth it to work with you to break the existing paradigm long enough for the fog of ‘solutionism’ to clear, and to help you get clarity on the range of outcomes that are possible given the problem you’re trying to solve.
Is There an Industry Standard for Discovery?
Yes and no.
We pull from several different frameworks, but there’s a lot of static out there. Discovery is often happening at the same time as analysis of a business case. For validation of a business case, we often use Lean Canvas for our startup clients, and if our client hasn’t already gone through this exercise they often find it adds clarity to their problem statement. There are similar frameworks for established companies, but we haven’t had to go much farther than the Business Model Canvas (which is about the same as Lean Canvas). We’ve run essential BRIDGeS scenarios, but we haven’t found that it (BRIDGeS) takes us much farther than the basic Lean Canvas for either Enterprise or startups.
We like and emulate the shape of Design Thinking, but we think that the name alone isn’t enough to get people on the same page. We usually have to walk a client through all the activities we’re going to do before we intend to start producing designs and prototypes so that they understand what we are going to be spending time (and their money) on.
In Discovery itself we tend to use whatever vocabulary is most familiar to our client. So we always go through iterations of something most people call Exploration / Validation. Sometimes we call the same process ‘Ideate / Evaluate’. And sometimes if we’re doing something that passes for basic brainstorming we call it ‘Converge / Diverge’ to reflect the phases of group solution-finding.
There are all kinds of Discovery frameworks out there. Design Thinking. Jobs To Be Done. Riskiest Assumption Test. Whatever we find works, we use. And as we go along we document our best Discovery practices.
What Does Lab Zero Discovery Look Like?
If you think of Discovery as ‘everything that has to happen before your first development sprint’, then you can imagine that Lab Zero Discovery comes in three phases:
- Clarify the Why
- Define the What
- Prepare to Sprint
(Note: Discovery can and should continue in a repeating cycle during the engagement, but this part of Discovery that happens before development starts is especially visible to clients, and so we discuss it here.)
Clarify the Why
During this phase we ask a lot of questions, build empathy for our users, and examine secondary research. After this phase, you’ll have a clarified, problem statement with scoping. You’ll have a map of today and a set of learning goals that prototype testing with real users can and should fulfill.
Define the What
During this phase we explore solutions, and evaluate them according to desirability, usability and feasibility. At the end, you’ll have a map for the desired future end state and a design ‘sketch’ which might be a prototype or a framework that will give shape and structure to future designs.
Prepare to Sprint
Here we finish everything we need in order to be ready to start Engineering sprints. At the end, there is a prioritized backlog, with highest-value estimated stories in a ‘ready’ state for development work. (Check out our Definition of Ready.) In the event that the first two phases of Discovery tell us that there is no need to build a feature, this phase also serves as a report-and-readout 'off-ramp'.
Are You Ready for Discovery?
If you’re looking for engineers to implement shovel-ready top-down specs, you may want to keep looking. But if you want an integrated team of designers, developers and product managers that brings you from Discovery to Launch, then we should talk.
Continue the conversation.
Lab Zero is a San Francisco-based product team helping startups and Fortune 100 companies build flexible, modern, and secure solutions.