These two should ideally mean the same thing, right?

Well, yes. But have you noticed a lot of products actually exist without solving real problems? When I come across these products, the first question that pops in my head is – Why?

• Why did they skip the most important step of product development – Discovery?
• Why did they choose to dive in headfirst without validating user needs?
• Why did they spend so much (well, it’s no longer expensive to build products anyway) building this pretty looking app that really has no USP?

I have so many questions but first I’d like to apologise for being out of commission for a while. Or should we pretend the last 6 weeks didn’t happen and skip to the good part? Naa. Retrospectives are good. I won’t bore you with the details though, especially since I already wrote about it here.

Ok! Just one more quick by the way – If you’ve developed a routine or habit, try as much as possible to stick with it. Gosh! I left regular writing for a few weeks, and it’s been a struggle getting back. But with you in my corner, I know we’ll get back in sync soon.

Done gisting. Back to products and solving problems.

So, what’s a typical ideation process? Let’s even leave the frameworks for now. How do people come up with solutions (read products)? They either encounter a problem in their own lives or around them and decide to solve the problem. Great! This is an ideal problem-solving approach. However, in a lot of cases, the solution is not commensurate with the product. Will the product solve the problem? Yes, but did we need that particular product to solve that problem? Probably not.

Am I rambling? Sorry. I told you I’m rusty.

Let me illustrate.

So, let’s say we have identified a housing problem for a homeless person, and we want to solve that problem by providing him accommodation. To solve that problem, we decide to build a state-of-the-art mansion. Have we solved the homeless person’s problem? No!

Lol. I can feel your eyes rolling – but the mansion does solve the accommodation problem.

Well, the issue here is that we’ve used gun to kill a housefly. Will the fly die? Probably, but there are two key issues with this approach–

1. Cost of investment – we’ve expended a lot of resources to build this house that the homeless person doesn’t need.
2. Time to market – dude is homeless! All he needed was basic shelter that could have been a makeshift shed with basic amenities. In fact, by the time we finish building our mansion, our client may have died of frostbite.

We clearly made assumptions of the user’s (homeless person) needs. Even though we had good intentions, and even if the product (the mansion) was ready early enough to provide value to the user, we most likely ended up confusing the user with too many options and they’ll probably be back on the streets in no time.

So, what should we have done differently?

1. Discovery!

Every product development framework emphasises discovery and that’s simply because we build products to solve problems for users. Users are the most important part of this equation. You don’t want to build a product that nobody wants to use. Discovery involves a lot of research, user engagement, empathising, analysis, and definition of user problems. The aim of discovery is to ensure that we understand the problem from the user’s perspective before we even begin to think about solutions. It’s also important to note that discovery is an iterative and incremental process. We need to keep going back to the user to validate our assumptions and test our hypotheses.

2. Assumptions Validation.

There will always be multiple ways to solve problems. The best place to start is the simplest solution. This way, we can quickly identify the flaws in our assumptions and fix them or go back to the drawing board if required. Building a mockup or prototype helps us visualise the solution. Please note that I did not say MVP. A prototype or mockup gives a basic representation of what the product will look like. An MVP is a small step higher, but MVPs don’t necessarily need to be a version 1 of your product. For instance, your MVP can be an excel sheet and a google form!

I have an upcoming class on MVPs this month. It’s FREE. I’ll send you a link to signup next week, so please mark my emails as important.

3. Incremental Building.

You thought Agile, didn’t you? Exactly. Solving the immediate problems first gives us clarity and helps us focus on the right things that the user actually finds valuable. For instance, building a 20-room-mansion for a homeless person doesn’t solve their immediate need and may not be of value to the user.

4. Data!

Another key consideration for solving valuable user  problems is the importance of data. Every kind of data is important – data from product usage, market data, competition data, user feedback, resource availability data etc. I say this all the time – data is a product manager’s most important weapon. We make informed decisions because we track and analyse data. Listen to the data, it will take you on a journey of a lifetime!

Produqtedge helps companies build tailored product strategies, scalable products & product teams.

Join our growing community of product managers, product leaders and founders for mentorship and coaching opportunities.

Join Produqtedge Community