How to Avoid Common Mistakes When Validating Digital Products

That’s where product idea validation comes in. This ensures you don’t waste time and money on a product that just doesn’t work or has no market need. In this episode of Disruption Talks, a panel of Netguru experts explains why rapid prototyping is the solution to testing your ideas.

On the show is Jinder Kang, Innovation Consultancy Lead, Patryk Szczygło, Senior Consultant of Research & Development, and Paweł Drożański, Senior Node.js Developer.

What is product idea validation?

Product idea validation is a process where a product, service, or business idea is tested in various ways to determine its validity and viability.

One way of testing a digital or physical product is through rapid prototyping. A prototype helps you avoid pouring time and money into scaling a product that needs extra work. Prototyping allows you to test your idea and product on users to see how they find it, what needs improving, or whether the product is viable at all.

Filip Sobiecki: What is the role of R&D in companies?

Patryk Szczygło: R&D at Netguru is all about helping clients with experimentation. If a client comes to us with an idea, we help them make the business case for that idea. We try to research topics if it involves advanced technology, and then we make a prototype that we can validate with users or show to investors.

Paweł Drożański: A lot of companies that come to Netguru want to create some very cool stuff but don’t know how to get from that point to having a final validated product idea. We help to validate those ideas and market fit and get them to that point.

R&D spending worldwide is $2 trillion annually. Do you have any examples of projects where R&D helped a company?

Patryk Szczygło: One example was a Click and Collect idea that we did rapid prototyping on. When COVID came, they needed a solution really fast to help people buy things quickly during the pandemic. We basically cut out most of the features you’d expect on a shopping app that weren’t relevant, like saving products for later and so on.

We had a basic cart system and information on where to pick products up. The good thing about a prototype is that you can make quick iterations without spending half a year developing the MVP, and you can get quick feedback on it.

Paweł Drożański: One example was Netguru’s internal Bob the Bot, which is a cool virtual assistant. A lot of companies can benefit from having software automate stuff for them. So, we created an internal tool with lots of modules and plugins to help the company speed up repetitive work.

Jinder Kang: An example from outside Netguru that I like is OpenIDEO, which is all about how we solve social problems. Rather than trying to attack the problems with a few minds, it’s all about bringing the power of the crowd and experts from different fields to work together.

Let’s flip it. Can you think of any examples of bad R&D or where it was sorely needed?

Jinder Kang: I would say not undertaking prototyping and building on assumptions is my biggest pet peeve.

You might have a wonderful idea, you may have validated it with your friends, but that’s not enough.

A lot of businesses end up sinking tens of thousands into an idea that hasn’t been tested properly.

Patryk Szczygło: Going straight into developing and putting a lot of money in some product that may fail or succeed, rather than making short iterations and testing them, is a big problem.

Paweł Drożański: One example is when a client came to us who wanted to create a product that allowed hotel guests to give feedback. It was a straightforward idea, but the owners went straight into building a big MVP without really understanding what the most viable product was. Development lasted about eight months, and there were a lot of extremely complicated features. In the end, there was no real market fit for it.

What do you think is needed to make the path from idea to MVP easier for entrepreneurs?

Jinder Kang: Normally, we want to start with a kind of framework. We want to discover, understand, and empathize with the current market. From that, we would normally move into gathering all the data and taking those learnings to define the real challenges at hand.

Next, we move on to the development of ideas.

At this stage, we map out our assumptions and hypotheses to test out before moving into delivery and demonstration.

This is where the prototypes come in, and we validate or invalidate the ideas as we go. By the end of this process, we turn assumptions into knowledge.

Patryk Szczygło: When we start with an idea, we look at business use cases and then go into a design sprint.

How differently would you approach a client with a big budget versus one with a low budget?

Patryk Szczygło: I don’t want to distinguish between big and low budgets because we try to make it the same for each company.

We want to help clients experiment on what will work for their customers.

With big-budget companies, once they have a prototype, they can just scale up and continue. For those with lower budgets, they have the opportunity to do the same if the idea works. If it doesn’t work, they can move on to another idea without spending all their budget.

Jinder Kang: The whole point of prototyping is that it limits the need for such large budgets. It is the best option regardless of whether you're a big company or a small company to ensure you're building the right thing.

What happens after rapid prototyping?

Patryk Szczygło: Basically, we have the prototype, it’s working great, it’s going to bring money in, now we need to create a roadmap. It’s really important for consultants to help the client create a proper roadmap because the client is often excited by this stage, so we need to keep things on track. We need to take small steps and avoid overwhelming the product with lots of new features that complicate everything.

Jinder Kang: The reason you don't want to go to the prototype stage with loads of features and functionality to test is you will struggle to see true cause and effect. If you have 50 features, you won't understand what the most relevant ones are. It’s also about speed to market. That's the other big reason that we want to try to reduce the number of features.

Paweł Drożański: I would add that another important stage is measuring.

Many founders forget that they should rely on users and their behavior in the app.

We need to look at how we measure everything with A/B testing, performance tests, and so on, to validate the client’s business approach. We can add in 50 more features later on, but they must be measured. The founders must know how that impacted the product.

What’s the most common challenge you come across?

Patryk Szczygło: For me, it’s the scope that’s always the problem. Some clients will focus on quantity over quality. You can have one feature that works the same as an app with three or four extra features that just disturb the user. You can add lots of other features in the future, but in the prototyping stage, it’s about testing the core features.

Paweł Drożański: Another I’d add is not understanding the users and their behavior. For example, if we create a VR application, and users don’t know how to use it because they don’t really need it, this will be a problem for founders.

This discussion is part of our Disruption Talks recordings, where we invite experts to share their insights on winning innovation strategies, the next generation of disruptors, and scaling digital products. To get unlimited access to this interview and many more insights from industry experts, sign up here.