Don't reinvent the wheel if it already exists

Don't fall victim to solving already-solved problems. How to recognize common problems that don't need a special solution, and how to tackle unique challenges.

👋 Hey, it’s András here! I write about all things product management: concepts, frameworks, career guidance, and hot takes to help you build better products. Subscribe for each article to be delivered when it’s out!

Product management is about solving customer problems. In most discussions, two types of problems arise: common and unique problems. While common problems are easier to address (how the search works, what shape the profile picture should be), solving unique problems will contribute more to an organization’s success.

In this article, I’ll cover what common and unique problems are, how to recognize the type of a challenge, and effective ways of dealing with unique problems — from mapping out constraints to testing possible alternatives.

But first, let’s clarify the definition of these expressions.

Common and unique problems

Common problems are solved by many existing products in one way or another. Things like how picking dates works, how to label things, or the basics of tabbed navigation. While the details might be a little different, the core concept is the same, and the best practices are widespread.

It’s easy to take inspiration from another product and apply similar principles to ours. Common problems and their solutions are typical examples of don’t reinvent the wheel if it already exists.

Unique problems, in contrast, are specific to a company or an industry. They’re not solved by many other organizations, so the approach can’t be copied. Problems like how to moderate content on scale, how to reduce a computer’s power needs, or how to make paint dry quicker.

Often, it’s more important to solve unique problems well than to have a perfect answer to common challenges. As in many cases, a great solution can make a product win over the competition. Just remember how many people use “googling” instead of “searching”.

Google recognized that the performance and quality of search are equally important.

So why should we recognize unique problems?

First, to focus on what really matters. If someone spends long hours coming up with a solution to a common problem, that’s most likely a wasted effort. Common problems rarely need huge investments because good patterns are already publicly available. We just need to pick one approach and fine-tune it to our liking.

Second, unique problems need systems thinking. When solving complex problems, we need to consider how different alternatives can affect a whole platform, what aspects of existing solutions might need changing, and what features will be affected.

Third, as discussed above, the solution to unique problems is just more important to get right. Getting them wrong at best will cause some user experience friction, but at worst, it can tank a business.

When doubting the nature of a problem, try the following questions:

• Has anyone done something similar inside our company? (Integrating a new data source to a data pipeline might not need a new approach.)

• If not, has anyone done something similar outside the company, but within the industry? (The way to handle customer complaints for reservation systems might have its unique attributes, but might not be a completely unique problem. And it’s easy to benchmark how Booking.com or Airbnb is handling cases.)

• If not, has anyone done something similar outside the industry? (Large language models were first used for specific use cases, but then they spread out to healthcare, finance, marketing, and other industries.)

If there are no good solutions to benchmark, we’re likely dealing with a unique problem.

Solving unique problems

When drafting some search functionality, the design of the search bar is less of a question, as there are well-established patterns for that. But how the results are displayed or what can be considered relevant are the points to spend time on. But unless someone is building a Google competitor, the feature doesn’t need a lot of unique thoughts — so at the end of the day, it’s a common problem.

In contrast, unique problems need a different approach.

1. Constrains mapping

A great solution requires a very good understanding of the challenge. Get acquainted with the details of the problem, the wider context, and map out possible constraints. Does the team know enough to come up with a great solution? If not, this is a good opportunity to dig deeper.

Maybe there are some hard technical limitations (maximum number of API calls), or there is a product decision you need to respect (in what cases user data is deleted).

Consider here both product logic and technical constraints, but don’t treat them as unchangeable. Every now and then, good solutions require challenging existing patterns.

2. Time allocation

One anti-pattern of a well-thought-through solution is rushed decision-making. Maybe there is an internal deadline, or an executive would want to see progress by a given date. Unique problems need detailed thinking, and it’s hard, if not impossible, to come up with the best way to solve a difficult problem in hours.

Ensure that the team has ample time to understand the details of the situation and come up with at least two alternative solutions.

Why two? To avoid falling into the trap of going with the very first idea. And the two approaches should be unique, not just two different designs of the same solution.

3. Low-effort testing

Once the team has settled on a few ideas, test them out in a relatively low-effort way. Hallway testing, quick-to-build prototypes, or even drawing user flows on paper can work here. Find something that doesn’t take days to work out, but would enable you to present the ideas to others. Colleagues who are aware of the area are the best to contribute here, as they are already in the context.

In terms of the time investment, follow a 70-30% rule: if it took 7 days to come up with the solution ideas, spend no more than 3 days to test them out.

Working with the ideas hands-on is also a great opportunity to see how many edge cases the alternatives would create. If too many, chances are that it might not be the best solution to the problem. Or that some constraints need to be changed.

4. Solution decision

Once the feedback is in, it’s time to pick a solution!

Select the approach to move forward with based on the feedback received, your hunch, and the overall development effort — and in this order.

If there is a clear winner, and it aligns with the initial belief, then there is no question that the team did a good job solving the problem.

If there are very different opinions, but your gut is telling you to go towards one specific solution, trust that feeling. Product professionals develop good instincts over time in their area, unconsciously evaluating decisions from different angles.

And, of course, consider the development effort too. It can happen that the best solution requires the biggest effort. If that’s the case, weigh the effort vs. the consequences of going with any of the other choices. If other options would create more pain in the future than comfortable, maybe it’s worth picking the first approach.

Takeaway

Product managers deal with a lot of decisions every day. While some are less important, others require thorough thinking and evaluation — just like unique problems.

The most important thing is to recognize them. There are a few things that set them apart from more common problems. Most importantly, that their solutions are not straightforward.

Once we find a unique problem, we can address it by taking a look at the context, spending some time crafting solutions, coming up with multiple approaches, and then validating the idea with other people around us.

And remember, when it comes to common problems, don’t reinvent the wheel.