We’ve lined out some features that make a good product discovery team great in a previous article, but what’s the deal with a product discovery anyway? Why is it so important? And are there any peculiarities innate for a custom project that you should know about?
Product discovery is a product development stage aimed at, despite the name, not just figuring out what the end product should look like but why building it in the first place.
The product discovery team’s goal is to understand the initial problem the product is supposed to solve or a feature idea at such lengths that further work can be organized correctly. The real trick here is to take enough time to focus on the problem before jumping to solutions and to collect proof instead of falling into biases. That way, the discovery process will bring most results.
That’s how one would prepare for their own project. But does it make sense for custom project development? Clients tend to literally tell you what they want to get and have rather strict deadlines, so wasting time on why’s instead of how’s is abundant, right?
Wrong.
First of all, gathering a client’s requirements doesn’t mean understanding them. And without understanding, there’s very little chance to make a decent product.
Second, a client being the end-user of the final product is merely a case. This means that not only should the product deliver the client’s business goals but also meet end users’ needs, and it’s a whole other bunch of questions to resolve.
So, product discovery is mandatory for pretty much every product development, as long as you want to make a truly needed and commercially successful one. Custom projects require product discovery just as any other does. That being said, the process is a bit different. In this article, I will share our experience with product discovery for custom projects and why we believe that sticking to this stage is the sure way to increase the likelihood of a successful product launch.
The customer can contribute to the development process significantly
Inventale has been launching high-tech projects based on machine learning and artificial intelligence methods since 2015. The team created dozens of projects under their belt which, in seconds, complete tasks that usually take up to several hours or are not feasible for a human to perform at all. Our experience allows us to estimate core technical project requirements on the fly.
In contrast, our clients are experts in completely different areas they want to improve with the help of technology. They are focused on seeking user needs and business opportunities, not on nooks and crannies of the development process - that’s what we help with. We don’t expect our partners to provide us with a comprehensive project layout to follow. Instead, we work on it together with them.
The partner possesses market insight and a promising product idea, and we are experts in product development. Our collaboration is all it takes to find a great solution. That is why we actively involve our clients in product discovery as experts in their area. Together, we can develop a bright product concept, set viable requirements, and determine optimal specifications.
Custom project development entails some extra needs and limitations
Product discovery is a strenuous process. The team constantly switches between posing a problem and figuring the solution, and there are just so many problems to solve. And it doesn’t get any better when you work on a custom project.
The development team has little to no control over the client’s budget, technical capabilities, and timeframes. Hence, developers have to figure out how to manage in a limited timeshare, within a limited budget, and with tools available to the startup.
99 times out of 100, the client isn’t an end-user of the future product which leaves the team with twice as many problems, often contradicting each other, to address during the product discovery phase.
To maneuver in this chaos is a form of art, but it can be mastered. The key is planning, focus, prioritizing, and adaptability (okay, maybe that’s a lot of keys):
- There’s always an initial and prior goal the product is supposed to achieve, and all the planning should ensure that it does. But keep in mind that plans will be thwarted, so plan setbacks too.
- There will be many issues to resolve, and many side questions will spawn in the process. The focus is essential for keeping discussions on track.
- Time is money, and different problems cost differently. Allocate the time to a given problem according to its priority - sometimes you have to cut that time budget, and sometimes be more generous.
- Probably the most important one: the product discovery’s goal is not to find a perfect solution. It is to find a solution perfectly suited for these imperfect circumstances. It is to adapt what you have to get what you need.
The team’s task is still to define what the product should be and how to get there. However, it often means finding a compromise and organizing future development according to the scale of the problem, level of the team’s competence in the given area, timeline, etc.
The product discovery team should include both people who know the end-users and will develop the product
Product discovery is a crucial step of product development, as deciding on the product’s goal, architecture, and design is pivotal to the project’s success. It only makes sense that the product discovery team’s line-up is no less important.
There are a couple of ways to go around a product discovery team configuration.
One is to assemble a separate product discovery team whose sole purpose is to handle only this particular stage of product development across all company’s projects. It allows the team to hone their skills and perform exceptionally well in homogenous projects.
The second is to engage one team throughout the entire development cycle of this particular project, from product discovery to product launch. This is our strategy of choice. It saves us time, gives the team full context and ownership over the process, and eliminates the inevitable risk of misunderstanding between separate teams during knowledge transfer.
Either way, core roles involved in any product discovery are product manager, UX-designer, researcher or analyst, and development lead. However, this list is not exhaustive. Depending on the project’s specificity, you would also need non-regular participants such as sales or customer success team members, CPO, maybe even DevOps engineers, and other specialists.
What is different about the custom project is that the customer team’s specialists may cover some of those roles.
Another aspect is that, again, the final product should appeal to both end-users and stakeholders. Engaging the client usually solves the stakeholders’ part, while figuring out the target audience’s pain points could use customer team members’ help. So, we’d argue that the core team should include user-facing specialists on a regular basis.
A proper product discovery opens an unhindered path to a successful MVP
Even brilliant ideas can still turn out as wacky products. That’s why you don’t want to progress too far into the implementation without testing waters with a minimum viable product - a simplistic version of the future product that hopefully adds value nonetheless.
As the product value comes from its core features, defining MVP scope stems from a feature prioritization. Generally, an MVP implementation planning involves both UX and development teams:
- mapping user stories,
- assessing technical possibilities and limitations,
- scheduling feature releases accordingly,
- coordinating the proposed scope and release plan with interconnected processes on the client’s side, i.e., marketing campaigns.
These steps are easily covered within product discovery as it’s dedicated to understanding user needs and use scenarios and deciding on the product design bearing in mind available means. Conveniently, product discovery also results in a list of prioritized backlog items, making it extra helpful for organizing the development process.
Next, when the customer participates directly as an expert, it significantly eases the coordination between the teams.
Basically, with a product discovery performed, an MVP is all set to go.
As a bonus, here’s a simple tip for prioritizing features: use the Effort/Impact matrix and its variations.
Grading features into four straightforward categories helps to balance the technical difficulty and potential value and rely on objective facts (or at least honest estimations) instead of guesses in doing so.
The product discovery team needs both leeway and timeframes
The product discovery method suggests that you dive into a project not predisposed to any exact idea of what the product should look like. In return, the final product yields better results, so it’s a fair price. What can be bothersome in the case of custom projects is that no set destination strips you off of clear deadlines as well. This may seem especially risky to teams that used to work with more classic time-based roadmaps, timelines, and even waterfalls.
But creative freedom doesn’t cancel scheduling. An experienced product discovery team accounts for the customer’s limitations, and time is one of those limits. So instead of following strict top-down roadmaps and task lists, the team figures out what can be done and prioritizes tasks to fit them within these timeframes. Other than that, the routine isn’t too different. The team still has regular check-points, timelines, and ETAs.
Sure, it’s easy to get overwhelmed and spend too much time on research and discussions as there are always more details and cases to analyze. However, this flaw is easily surmountable by organizing the work process:
- The team needs clearly defined expectations and timelines to assess how critical the task is, when it should be completed, and, therefore, how deep to analyze it.
- Regular check-ins help to reveal issues the team is stuck with and find the solution before messing up the work plan.
- Finally, it is a matter of maturity. The more the team uses this framework, the more comfortable they are to use and adjust it for themselves.
Every project and product is unique, but what successful ones have in common is that they check in all the boxes right - timing, audience, tools used, and business specifics. For our products to be part of them, we listen to the customer and collaborate.
There are many cases when your expertise is enough to deliver a solution as soon as possible. But when the situation is more complicated and requires research, we hope this article can help you to do it as efficiently as possible.
