Product Discovery And Delivery- At Odds With Each Other?

Product Discovery And Delivery At Odds With Each Other

From having a product discovery workshop to a product’s delivery (or execution), there are quite a few challenges that fall along the way of the team that works on its development. If the certainty of the digital product’s release grows to be uncertain along the lines of its execution, there is a higher chance of errors, and ultimately, risks – risks that could lead to a poor display of the product in the eyes of the consumer.

Let’s say, for example, two different companies are working on a digital product.

In the first scenario (Team 1), the team knows what they’re doing. They set up a product discovery workshop (either themselves or in coordination with a company that is able to help them streamline their resources), letting them set the baseline for their approach towards the delivery and the market. The problems and solutions are identified, allowing there to be clarity in the initial stages, and in turn, the delivery is planned accordingly. The team will be ready for the next steps and have a roadmap of what needs to be done and when. The execution will be done smoothly, allowing the team to work and deliver efficiently.

On the other hand, there is a different company working on the delivery of a digital product. However, unlike Team 1, there is no clarity as to what the product is meant to achieve in the market. They decide to skim through the process and are left with nothing but mere insights that give them a hint as to what needs to be done. Confusion is left in the minds of the team members about the objective and the end goal is either discarded or left unachieved.

To put it simply, we learn how accurately or inaccurately the discovery phase helps in envisioning the ideal digital product.

Let’s dive into a little more detail:

1. Discovery in detail

For starters, what is product discovery?

Product discovery is the process of running through a cycle of research that allows the team working on the digital product to understand their customers furthermore. A certain period of time is dedicated to this research, allowing the team to explore the question “how can I build the right thing?”

One of the most common errors that software teams can make is to take the approach of product delivery – one that answers the question “how do I build the thing right?” To answer these questions, you need to gain a deeper understanding of your business model.

As you can see, the two questions reap different solutions. The reason why product discovery is so important is mainly because it allows you to study the consumer. Even if you create a digital product, one that works well and does what you expected it to do, the product is deemed close to useless if it doesn’t have an audience waiting to use it.

Understanding customer solutions with the help of product discovery is the first step towards a well-thought-out launch. If you learn fast, you deliver faster

2. Robust and scalable implementations

Okay, so we’ve learned about customer solutions but what comes next? Building a robust and scalable implementation of the digital product in the market.

It’s the dream (if not the need) of every product manager to release a product that’s going to be 100% ready for the market, clean, pristine, reliable and overall, the ideal solution to the problem of the consumer. But how much of this is really achieved? 

Most of the time, software teams are made to be involved in the ‘solution’ phase of the product, i.e. when the creation begins. The question arises – how do you build a flawless digital product without involving the creators amidst the brainstorming sessions? And will you, as a team, ever be able to achieve the result you desire without allowing them to be a part of product discovery?

If you want to be able to provide a consistently reliable digital product, you need to understand all the possible risks in the discovery stage itself – which is where the software team comes in.

3. Enough features in MVP?

When we speak about the list of risks that come attached with a product’s delivery, many factors contribute to it. Like how economies of speed trumps scale in digital transformation these days, especially after the pandemic.

As discussed earlier, even though a digital product’s potential might be of a grand level, the delivery normally doesn’t match up. Without the involvement of the software team through product discovery, most of the features needed to limit the risks of its delivery tend to go missing. Ultimately, this leads to the creation of a minimal viable product (MVP).

Many a time, this tends to be discouraging for both the company and the teams involved in the launch of the digital product. This is mainly because even though you’re practically putting yourself “out there” and exploring the feedback of the customers as soon as possible with the MVP, you’re also risking putting your company and team in a compromising situation where you allow the audience to believe that this is the best you could come up with.

Even though we hate to believe it, the first impression can last longer than it should. If the consumer does not feel encouraged enough to come back to the MVP as it enhances, then you’ve already lost out on the necessary features required for its launch.

4. Getting feedback without pushing the users

client reviews

Realistically, an MVP is supposed to have ‘just enough’ features to keep a consumer interested. If your team has been able to work that out, then your launch could be done successfully – you’ll be able to gather substantial feedback and you can accommodate all the necessary changes.

However, a digital product’s launch isn’t just about the product – it’s also about the consumer. Think about it – do you have customers that pursue your business already? Or do you still have an audience to build?

On the first hand, if you have customers pursuing your business then you need to be careful about the risks attached to your MVP. The product is supposed to help you drive more customers in and not take the ones that you already have, away.

In the second scenario, if you don’t have any customers attached to your business, then you might feel the urge to try extreme measures to gain feedback – online forms, invitations, etc. However, we suggest following the protocol of a customer development program. Since this is a team composed of consumers that want to interact with digital products and give feedback, you hold a much lower risk of losing the trust of your potential audience.

Preparing a user journey map is one of the first steps needed in gaining the right feedback. This can help you streamline which review is important, which isn’t, as well as what problems were mentioned over and over again. When you gain a clear understanding of the product requirement, it’s easier to build a strategic wireframe.

5. Rapid experimentation and Discovery - II

The cycle of discovery and delivery goes hand in hand. Once you finish the initial brainstorming session, you go forward with a test launch with your MVP. The MVP drives feedback from a set of customers that allow you to learn what your product lacks.

Now, once you have the feedback, it’s important to get back to the drawing board. What comes next? Sure, all of the feedback is important but how much of it is feasible? Which team needs to get to work? Was a part of the feedback predicted during Discovery I? If yes, you already know the next steps – if not, it’s time to begin.

During the second stage of discovery, you will realise how quickly things can move as long as the right teams are involved. While stage 1 allows you to get your hands in the game, the second stage allows you to learn more deeply about trial and error.

6. Small, incremental changes to a complex system

Trial and error bring us to our next step, the small incremental changes you need to follow through with.

Generally, this is the step that brings the entire team together. Since all of you have already witnessed the launch and feedback of the MVP once, the ‘want’ for a successful product delivery becomes even more integral in the eyes of the teams. You want to succeed, which is where everyone puts in their all.

Software teams, design teams and more work together on tiny but substantial changes that determine the growth of the digital product from a minimal viable product to a product ready for the consumer.

7. Delivering solid software

While the process might look simple, it can be difficult to implement.

As mentioned at the very beginning of this blog, we tend to rush the delivery of a product from the very beginning of its discovery and while this can be motivational for some, it leads to the failure of both discovery and delivery in most cases.

Look back at the digital product launches that you have carried out as a team. Once you come together and look back at a launch by considering all the hiccups that occurred and what the true potential was, you will be able to learn from your mistakes and know what to do better the next time.

The process of product discovery and delivery is a learning process. Since the scope is massive, the pressure tends to be at its peak always, as well. However, that is the fun of learning and growing with a team that wants to deliver perfection.

At GrowExx, we believe in bringing together teams through the run of product discovery and delivery to be able to execute in a way unlike any other. Through teamwork and mutual understanding, every team can bring forward a problem and solution the others might not even consider.

Through teamwork, we deliver.

mobile app development services
Vikas Agarwal is the Founder of GrowExx, a Digital Product Development Company specializing in Product Engineering, Data Engineering, Business Intelligence, Web and Mobile Applications. His expertise lies in Technology Innovation, Product Management, Building & nurturing strong and self-managed high-performing Agile teams.

Table of Contents

Subscribe to our newsletter

Share this article

Looking to build a digital product?
Let's build it together.

Contact us now

  • This field is for validation purposes and should be left unchanged.