“We should remember that good fortune often happens when opportunity meets with preparation.” – Thomas A. Edison.
I know how it feels when you’re excited about a new software project. You’ve lived with this idea for some time, and now you’re eager to start. Taking more time for preparation sounds crazy, right? But it’s a proven way to lay a solid foundation.
A whopping 35 percent of startups fail because they don’t find a target market, while 45 percent of big projects (>15 million USD) face cost overruns due to missed focus, shifting project requirements, and unrealistic schedules.
Why do you think the numbers are so high? I believe it’s because for most people, rush and excitement prevail over preparation.
I myself have seen how skipping the first development stage damages the whole project. This is the main reason why I’m here today with a detailed overview of a project discovery phase. Why not take the initiative to prevent issues instead of handling them once they happen? Let’s find out how.
What Is a Discovery Phase Exactly?
The discovery phase is the first stage of the development process. If developers aren’t writing code immediately, it doesn’t mean that your project isn’t progressing. On the contrary, preparations contribute to the higher quality of the finalized product.
The discovery phase of a software project is a process of gathering and analyzing information about the future solution itself, its market, its competitors, and its target audience.
This phase allows you to decide if this project is worth the effort in the first place. And if it is, discovery will show you how to make things right. For this reason, a discovery group includes a business analyst, project manager, account manager, developer (tech lead), and UI/UX designer. This group can be bigger or smaller depending on the project’s risks and complexity.
How long does the discovery phase take?
This initial project phase can last from a day or two to more than a month, and it’s completely okay. More innovative projects naturally require more time to delve into.
Here are some approximate timeframes:
- Small projects: 1–3 days
- Medium projects: 1–2 weeks
- Big projects: 4 weeks or more
The phase’s budget depends on the number of people involved and their hourly rates or a provided fixed cost.
Why Should You Bother? Top Business Benefits of a Well-Built Discovery Phase
I often see clients resisting the discovery process, and I can understand it. You’ve already had all these chats and discussions with your in-house team, spent sleepless nights considering all the details, and now you’re finally ready. The fact that you need time and budget for more research is so annoying! Why do they do this phase in the first place?
1. You get high-quality results right from the start.
Not only do you aspire to build an incredible product — your vendor wants the same thing. The discovery phase allows the team to understand what you want, look at the challenge from the technical point of view, and offer the full scope of tools and approaches. In other words, your team will be well-equipped.
2. Your product will bring revenue faster.
Sooner or later, project deliverables will be ready. Does it mean they will be successful? I agree that no one knows for sure, but you can be immune to a definite “no” thanks to thorough research.
By successful, I mean an increasing number of users and conversions. To suggest that, you need well-defined business goals and a targeted market. This clear focus will save you from failure when the product hits the shelves.
3. Your users will get what they want.
I’ve seen this a lot: great ideas exist in isolation from the end-user. But what sense does it make? In the long run, customers are the ones who keep your business afloat and allow it to grow.
Think like a user and share your thoughts with a digital team. Who is this user, and what issues do they want to solve? Does your digital product help them in some way? Let everyone on the project know who they’re working for.
4. Communication with your team will become transparent.
Overdue deadlines won’t ruin your project — wrong expectations and miscommunication do that. The general understanding of the project provides context to all decisions made afterward.
Explain your thoughts, ideas, and even fears to the development team — you’ll have enough time for that during the discovery phase. It will save you from dozens of unnecessary questions and corrections in the future.
When Do You Most Need the Discovery Phase?
Even though I strongly recommend the discovery phase to each of my clients, some cases require it the most. Here’s what I mean:
- Your product idea is not fully formed yet. Let’s say you’ve kept some basic concept in your mind, but you don’t know how to put it on paper. Or your idea seems too complex, and you don’t know where to start. Or you haven’t seen anything similar on the market, so you don’t even know if it’s doable.
- Several stakeholders can’t find common ground. If several people are responsible for your product, often they keep arguing about what’s best and how to make it work. It’s completely normal, believe me. And negotiations will go smoother if you hire a business analyst before project development starts.
- Your project is complex and/or innovative. In such cases, defining a scope of work becomes a real challenge for clients. They simply don’t have enough expertise to list all of the requirements in the technical language. Plus, the project should be divided into several milestones according to priorities — it’s hardly manageable with no expertise in the field.
- You have no room for error. Internal IT projects for enterprises involve fewer risks than emerging startups. If too much is at stake, the discovery phase will save you from a total business failure.
What Will Happen if You Decide to Skip Discovery, Anyway?
Speaking from my own experience, ignoring the IT project discovery phase invites negative consequences. These are the most common of them:
- You won’t get what you want. Even though technologies have gone far, people still can’t read your mind. Initial misunderstanding can lead to complete miscommunication by the end of the project. As a result, the final deliverables won’t meet your expectations.
- The project scope will continue to grow and change. Sometimes, the initial scope changes beyond recognition because the list of deliverables was never defined. The team loses focus and direction, and clients have to establish them anyway, but at a way higher cost.
- The budget goes beyond the limit. This is normal when you change the project scope. But the question is, were you ready for it at the beginning? Do you even have the resources to cover budget gaps? Answer these questions before you jump to the development stage.
- You’ll have to shift the deadlines. Or make developers work twice as hard. In the first case, you may miss your finest hour on the competitive market. In the second, you won’t get the quality you’re striving for.
- Changing an IT vendor will become a real challenge. With no basic documentation, experienced developers won’t get into your project. Why? They realize how much time it will take to understand the project in full. And even if they do it, the chances of changing it for the better are pretty slim.
What Should the Discovery Phase Include?
Now it’s time for actionable tips. To make sure you do everything right, keep these points in mind.
1. Analysis of the existing documentation.
The more years your company has existed on the market, the more it has to share. Provide any information that you think can be important for the project. You can also share your business vision, approach, company history, etc.
2. Defining stakeholders.
The development team should be well aware of who makes decisions and in what cases. Even if not all stakeholders will be involved in product creation, the vendor’s team can get a lot of insights by interviewing each of the interested parties.
3. Project goals.
A well-defined goal is a key to everything. It’s a clear vision of what should be done and why it’s important. You may be surprised, but not every client knows exactly what they want. It is like visiting a store with no idea what to grab from the shelf. Professional teams will help you outline your aspirations and determine priorities.
4. Success metrics.
Success is not an abstract term in business — its measurement is individual on a case-by-case basis. The most obvious metric is the return on investment, but stakeholders should agree on what they call a financial return (increased sales, number of users, improved engagement, etc.).
5. User research.
More often than not, clients don’t have a definite portrait of their target audience. The discovery stage covers that too. Also, the team has to “walk in the user’s shoes.” How will your solution help this person? In what circumstances? Sometimes, the best idea is to talk to targeted users directly to collect in-depth insights.
6. Value proposition.
Now that you’re sure about your goals and user portrait, you should see if they match. At this point, the team defines the product’s benefits and particular features that provide those benefits. Outlining those will also help your marketing team much later, at the promotion stage.
7. Competitors research.
Software solutions don’t exist in a vacuum, so the product development team should know the context around the product they create. Making the list of the main competitors and highlighting their strong and weak sides will help to find the niche for your solution.
8. Time and budget estimation.
After collecting the data from the previous points, business analysts, in collaboration with developers, can present a rough timeline and budget required to build your digital product.
Bonus Tips: How to Make Your Discovery Phase More Effective
There is some spice to add to the software development discovery phase. These are the tips I find the most helpful for a project of any size.
Make sure the discovery phase is proportional to the overall project. Why do so many startups or business owners find discovery unnecessary? They think they have to spend too much time and money. But they’re wrong.
A professional vendor knows how to make the first stage proportional to other development efforts. If you have a small budget, the discovery phase will be less detailed. It won’t be painful or exhausting; it will simply help you create a profitable solution.
Talk to everyone on the team. It’s normal to include a complex team right from the start. No one does better research than business analysts, no one will build a better tech stack than developers, and only designers can create worthy wireframes.
Innovative projects definitely need more attention from everyone. The way you set up the work now will impact the whole workflow in the future.
Treat the discovery phase as a separate project with deliverables. Specific results will demonstrate how time and budget were spent at this stage. Plus, you won’t feel like you were only talking with a team — you’ll already get the first pieces of project documentation. Speaking of deliverables…
The End Result: Project Discovery Phase Deliverables
Regardless of how long your product discovery has taken, it should be documented. No worries — you’ll have professionals by your side to finish it up. This is the most common list of documents:
- Project brief: a short description of the project’s vision and main goals. It may also contain some design and architecture details (but not an in-depth overview).
- Tech stack and project architecture: a technical document written in collaboration with developers. It determines the fundamental principles of the solution’s workflow.
- Design wireframes: the first sketches along with ideas on the style guide and user experience (navigation).
- Preliminary roadmap and estimation: information on the team composition, project milestones, budget, and roadmap.
The documents listed above will help at other development stages: requirements specification, design, and coding.
Not everything on the project depends on developers. Sometimes, business owners themselves put the whole team under pressure by ignoring thorough discovery and planning.
I know how the discovery phase in software development benefits all parties. It’s a chance for the client and vendor to get to know each other better and prevent numerous market and development risks. Trust me, I’ve seen how much diligence can be saved with one week of preparations.