Always look for the problem

When someone requests a product feature, a change to your ways of working, or raises any sort of idea, they typically come to you with a suggested solution.

• We should implement a live chat feature on our website to improve customer support.
• We need to develop a mobile application to increase our user base.
• We should integrate with Google Calendar to remind users about their scheduled tasks.
• Let’s create a referral program to attract new customers.
• We need to add push notifications to keep our users engaged.
• We should incorporate blockchain technology to ensure secure transactions.
• We need to build a comprehensive FAQ section to reduce the number of support queries.
• We should offer 24/7 customer service to better assist our international customers.
• Let’s invest in a new CRM to streamline our sales process.
• We should adopt product analytics to better understand our customer behaviour.

These requests are all proposed solutions. For some, it is obvious what problem they solve. For others, it requires some digging.

While these ideas all sound convincing, even the best sounding solutions can be flawed for two reasons:

• When you jump to a solution without exploring the underlying problem, you never get the chance to scrutinise the characteristics, importance, urgency, or ubiquity of the problem. Interest or excitement does not translate to importance. Sometimes, the most exciting ideas are superficial and solve unimportant problems.
• When you accept a suggested solution, you fail to consider other potential solutions¹. There is usually a simpler, easier-to-implement, and more effective option than the first solution that comes to mind.

Startups are idea-rich and resource-poor. So, spending your limited resources on the most important problems is important. Startups that chase exciting ideas and fail to scrutinise problems fail to deliver great customer outcomes and become mediocre over time.

Finding operational problems

While it’s common for product managers and engineers to look for underlying problems when they receive a feature request, teams rarely apply the same scrutiny to internal operational suggestions.

Ideas for new or adjusted ways of working are as common as feature requests:

• We need a weekly meeting between marketing and product to ensure we’re on the same page with new feature releases.
• We need to hire a product marketing manager to coordinate product messaging.
• If professional services and products met on a regular cadence, we could
• If product managers join kick-off calls with new customers, we can identify
• If professional services join sales demos, we can ensure the people responsible for project delivery have a hand in project scopes.

These ideas sound reasonable, so most organisations embrace such suggestions without scrutiny. But it’s problematic to jump to a solution, whether it’s a product idea or an operational change. As expensive as product development is, bad operations can cost even more over time.

More broadly, the inconvenient truth of startup and business operations is that there are no fundamental truths applicable to all businesses. Different business models and organisational structures may be biased towards certain operating principles. But, there are so many operating variables that every business should work differently. Ideas about operations, usually informed by experience in other businesses, can be as ill-fitting as even the worst product ideas.

So, startup leaders should examine every new and existing process for inefficiencies. More importantly, leaders should scrutinise new ideas.

• Various problems could lead a marketing team to request a weekly meeting with the product. Perhaps they’re frequently blindsided by new releases and don’t have time to prepare communications. Or there could be a lack of alignment between what marketing and product understand to be the ideal customer profile or value proposition. A startup can solve these problems in various ways besides an expensive meeting with an ambiguous agenda.
• Dissatisfaction with development velocity or product strategy undergirds most requests for a detailed product roadmap². Teams should instead address velocity and strategy problems or disagreements head-on. Velocity is a particularly insidious problem because most suggestions (typically more artefacts like roadmaps or more meetings) slow teams down.
• Professional services and customer success teams suffer when a sales team sells professional services that are particularly tricky or impossible to deliver. Professional services teams might demand involvement in the sales process as a solution. But, this would slow down the sales process. A startup that values sales velocity might consider other options, like standardising professional services to a point where it’s much easier to sell them.

Every startup problem has multiple solutions, and teams that operate effectively tend to deliver better results. So, it pays to spend a little time on each problem before you add a new meeting or process.

Finding customer problems

Understanding customer problems is a fundamental part of any startup’s operation, and this extends to product teams. They receive numerous feature requests from customers, yet the challenge lies not in implementing them all but in understanding the core problem these requests are attempting to solve. More often than not, these feature requests are solution-driven, highlighting the proposed solutions rather than the underlying problems.

When dealing with these solution-based requests, product teams must apply the principles of problem exploration. Instead of jumping straight into the suggested solution, teams should dig deeper to comprehend the root cause or problem that led to the feature request.

Let’s say customers are asking for an in-app tutorial or product tour. It might seem that the solution is to create a comprehensive walkthrough. But upon closer examination, the product team may find that the real issue isn’t a lack of a tutorial but rather that the app’s interface is not intuitive enough. In this case, a more effective solution might be redesigning some UI elements for a better user experience instead of investing resources in creating an in-app tutorial.

Suppose customers are requesting a feature to download and save content offline. At first glance, the solution is to add an offline mode. However, if the team investigates the underlying issue, they might discover that the problem is intermittent or slow internet connections impacting user experience. In this case, optimising the app for lower bandwidth conditions might be a more viable solution rather than creating an entirely new offline feature.

Another example could be customers requesting an in-app messaging feature. Instead of building an entire messaging system, the team should identify the problem. Is it because users want a faster way to connect with support, or do they want to communicate with other users? In both cases, implementing an entire messaging system could be an overkill when simpler, more effective solutions are available.

Unearthing the true problem helps startups better allocate their resources, focusing on the most urgent and important needs rather than getting carried away by exciting solutions. This ensures a more effective problem-solving process and drives customer satisfaction by delivering more targeted and useful solutions.

A startup capable of listening to its customers and, instead of taking its proposed solutions at face value, delves deeper to understand the real issues is one that stands a better chance of delivering a product that meets customer needs in a meaningful way. As such, always remember to place the problem first and the solution second. In doing so, your startup will make the most of its resources, cater effectively to its customers, and ultimately thrive in a competitive market.

Footnotes