The CTO’s Guide to a Killer Discovery Process: Part 1

A productive discovery process starts with thorough, collaborative requirements gathering.

Discovery lays the foundation for everything that happens during development.

Time spent productively in this phase has an exponential impact on a project’s chances of success - but it’s an unfortunate truth that discovery is often rushed.

Developers want to dig into an exciting project, or product owners are excited to start using a new tool.

Whatever the reason, a short discovery leads to a long road of misunderstandings and readjustments.

Running a killer discovery requires active listening and open communication.

The payoff is twofold: a smoother, more profitable development process and a better client-developer relationship that can lead to return business.

In this article, the first in a two-part series, explore the discovery process from initial interviews to preparing to create a prototype.

Why Discovery Matters

Discovery is a collaborative process that establishes the requirements necessary to build a specific piece of software.

By necessity it’s all about the client. Developers use interviews and probing questions to uncover the fundamental business problems or issues the client needs to solve.

When done correctly discovery:

This last point is a big one, and it’s the reason good discovery requires tact and insight.

Clients may not be clear on what they want. Sometimes they need help to frame their needs.

Discovery helps nail down the specifics to lay the groundwork for a productive development.

Client Interviews

Requirements gathering starts with interviews between the developer, the client, and relevant stakeholders.

This shouldn’t be a single meeting. Set up a series of sessions with space between to research and discuss.

Dig deep to understand the client, their business, and their existing processes.

It may be necessary to help the client identify stakeholders who should be at the meetings.

Listen to the client’s initial request, then question further to identify the true source of their pain.

They may think their problem is “our website is outdated and not driving conversions, so we need a new one” when the problem can be better stated as “customers are having trouble finding and using order functions on our old website”.

Be sure to touch on important issues like:

Before moving forward, come up with user stories that help articulate the typical user.

What experience would the client like to create for their own customers? Outline each step in the process.

This will help with the prototype as well as testing later in the process.

Competitive Analysis

Once the first set of requirements are in, it’s time to brainstorm solutions.

Start with what’s already working by researching the “best in class” solutions currently used in the real world.

Note what others in the client’s domain are doing. Evaluate how well or poorly those solutions have worked out.

The goal is not to copy others, but to incorporate the best thinking available into a better solution.

It’s like writing code- good developers build on previous work to start from a place of success.

It’s also a great idea to find inspiration outside the client’s direct competitors.

Look at companies who have similar challenges, then bring together the most elegant solutions to assemble a dynamic, enterprise-focused brief.

What comes next?

The bulk of the requirements are collected during these two stages, though the team should be responsive to change within reason as development proceeds.

Now that there’s a good idea of what the client needs, it’s time to visualize a solution by building a prototype of the projected software.

Learn more about how to build the most effective prototype in Part 2 of the Keys to A Killer Discovery series, coming soon.