What is Software Discovery?
Product discovery is a challenging but vital first step in the software lifecycle. You can compare a discovery study to surveying land and drawing a blueprint before a building project. While it’s possible to dig a hole and pour a foundation without a plan, the building isn’t likely to go very well.
A formal Discovery Study provides space for a shared focus on what we are trying to solve with software, and how that software solution can add value for you and your users. To really stretch the analogy, it’s taking the time to work out how many bedrooms and bathrooms your house needs, how big the kitchen needs to be, how you want to get into the attic, and how it all fits together to make one cohesive home.
It’s all about our Clients’ needs.
Just like you wouldn't start building without a blueprint, we wouldn’t want to start coding without clearly understanding your goals.
What is a need?
This should be easy, right? We all know what “business needs” are, generally - speed and ease of use, making sales, keeping the right people informed - but that’s part of the problem. If we start by assuming we know what your needs are, we can miss important industry- or company-specific marks.
Clevyr is an information technology company, and we’re experts at working with software. We’re not experts in your industry - that’s your superpower. We rely on our clients to help us understand the unique nuances the that affect their business. Whether it’s agriculture, banking, medical labs, or oil fields, every industry has distinct users and use cases, regulatory and legal requirements - just all-around different needs.
A need, as we talk about it here, is an agreed-on, high-level, user-focused goal to be reached or problem to be solved. Needs tell us what our clients must have or do to succeed. It’s surprising how often even a small and experienced team can have different views about what a project’s needs are, let alone how to solve them. That’s why the first step is ensuring our client stakeholders agree on their priorities, and then communicate them to us with context. Getting our teams aligned here builds the strongest possible foundation for a new project.
What is a requirement?
This is where we come in! A requirement is what we’ve all agreed the software has to do—based on your goals, user needs, and any outside constraints like laws or internal rules. (Formally, it’s the transformation of needs into specific obligations the product must fulfill, within defined limits and acceptable levels of risk.) That’s a mouthful, but it all matters. Most products serve multiple kinds of users, each with their own needs and requirements. These different users interact with features in different ways, bringing constraints and risks that may be unique for each user group. Add in industry regulations or internal policies about how certain things are done or who does them - you get the point. One need can easily lead to several requirements, and sometimes what feels like an easy ask is actually three or four needs in a trench coat.
Let’s Put That Into Context.
As an example, when a client tells us a web application needs to “notify managers when their employees request time off” it signals an easy to understand need with some sub-needs and a lot of complicated requirements hiding behind it. On the surface, we know there has to be logic to keep employees tied to their managers and employees have to have a mechanism to request time off, but just a little deeper there are more questions, that spawn more questions:
-
What kind of notifications should be sent? In-app, email, push notifications, SMS, or a combination?
-
How many employees does one manager have?
-
If it’s a lot, should notifications be bundled so the manager only gets one or two PTO request reminders daily?
-
-
How many kinds of time off are there? Do they all work the same way?
-
Should users have control over which kinds of notifications they receive?
-
-
Do these notifications need a “do not disturb” period?
-
If so, should it be global (for the whole app) or set per user?
-
-
How will employees make their requests, anyway?
-
Is it a form, or a calendar interface?
-
Will they access it from a high level menu, or a button on a page, or their profile, or?
-
It’s up to the project team to elicit these needs and use cases, and ask the questions so that we can tease out the hidden requirements and resolve conflicts, inconsistencies, and other issues, including “what else?” and “what happens next?” (Who approves that manager’s time off? What happens when a request is approved or denied? Does HR need an audit trail for all of this?)
We know that not every user wants every notification at every step, so it’s our job to talk through and confirm each decision point, then document the decisions. Discovery helps us figure out which notifications matter, to whom, and when. Maybe we’ll refine the notification types, or the recipients, or what triggers a notification - or maybe we’ll collaboratively create a whole different solution. Figuring out the needs, then applying the use cases, risks, and constraints lets us make sure the implementation addresses our clients’ needs.
Every line of code is a decision to make, and a product is made up of thousands and thousands of lines of code. So we want to make sure we get every business decision right.
–Aaron Krauss, Code Boss
Levels of Discovery
We offer several customizable Discovery Study levels based on where you are in your product journey, ideation, or funding rounds. Our team can help you identify what option will be most valuable to you.
New products (not yet developed) tend to need fully integrated design, business, functional, and technical Discovery. The word ‘need’ is intentional here, since the thing that fills a client’s need or solves a problem will always come to light eventually. It’s much easier and less costly to course correct and get things right in the planning phase than it is once the product is in development. To go back to the house analogy, you can visualize late, unplanned discovery as tearing up the slab to reroute the plumbing because the kitchen sink is in the wrong place.
Existing products can also benefit from Discovery. Common targets for Discovery for existing products are:
-
Design and user interface assessment
-
Accessibility assessment
-
Security assessment
-
Technical assessment (which can include the app’s code, APIs, database, and hosting architecture)
What Happens During Discovery?
We like to start with a day or two (or three!) of workshops to talk through and ensure alignment on the major aspects of your project. Members of the Clevyr Discovery Team will lead you through our Five Step Discovery Process, which includes helping define the overall vision, goals, strategy, teams, and design of your product. This process encourages conversation and drives problem-solving to help identify what success ultimately looks like for you.
Over the next two-to-eight weeks, you’ll keep meeting with your Clevyr team, at least weekly, so that our Development and Creative Teams can demonstrate our plans and documentation, gather your feedback, ask new questions, and keep building on the goals and decisions identified in the previous meetings. This continued alignment lets us narrow in and bring your project to life on a platform that makes sense for your goals.
Depending on the purpose of your Discovery, you may receive a range of deliverables, from a proposal to reports, design materials, or a clickable prototype. Functioning demonstrations and feature Proof of Concept development may also be included in higher level Discoveries.
Ready to Build the Right Thing?
Product discovery alone, like building plans, cannot guarantee success. What it can do is create a base of common understanding and direction for the rest of your product’s development. Whether you’re launching something new or improving what’s already out there, a Discovery Study helps you avoid costly missteps and surface the insights that matter most.
