Product management is the art of collecting information about a problem and distilling that information into a single cohesive solution. The biggest challenge of building a software product is figuring out what not to build.
1. Don’t Solve Adjacent Problems
When building a product, it is natural for ideas to start flowing. It is not too long before this ideation process ends up venturing into the land of adjacent problems. Brainstorming a project management tool might take a turn into discussions about chat. Things like billing and quoting come up often in products that deal with sales or time tracking.
Solving adjacent problems is akin to vertical integration in traditional businesses. Amazon did not start out with their own warehouses or stock. At their size and growth it was still many years until they built their own shipping fleet. Similar to the way vertical integration is a step taken when a business matures, solving adjacent problems is a step that should be taken once a product matures.
Questions to ask:
- Will your solution complement other solutions your customers already have or force them to choose between your solution and one they are currently using?
- What does their software ecosystem look like?
- What problems are being solved by their existing software?
2. Recognize and Avoid Exceptional Features
When a new product gets off the ground, there is sure to be feedback from initial users. This set of initial feedback is small and not statistically significant. At this stage of development, separating features that only a small subset of the target market will want from features that the majority of users will want is challenging.
The biggest risks for blindly implementing requested features is 1. The product will begin to solve specific adjacent problems that move the product away from the original solution 2. Few other customers will have this problem.
Questions to ask:
- To customer: What would you do if you couldn’t have this feature?
- How big is the problem to your workflow?
- To other customers: Are you also having this problem?
3. Apply the Pareto Principle to Features
The pareto principle (a.k.a the 80-20 rule) is just an observation of the Power Law at play in the world around us. When it comes to features, the pareto principle tells us that 20% of the features will provide 80% of the value or get 80% of the use.
Does this have to be the case? In products with a large number of features, it is natural that the value and usage of the features will follow a power law distribution. In small focused products, this does not happen. A good example is Google Search: the first step is entering the search terms and the second is viewing a list of matching search results. Those two steps may be considered one feature and thus we have a one feature product. Such a simple product will escape this rule since the feature set is small. Even Google Search over time has filled out the tail of Google Search features with features like a calculator, sports scores, and places. This 80% set provides 20% of the value and usage.
Applied to our own products, it is important to recognize when a feature is in the 80% that provide 20% of the value. These features should be pruned if possible, or prioritized below incremental improvements to the 20% that provide 80% of the value.
4. Apply the Pareto Principle to Integrations
Rule (a) states that we should avoid adjacent problems. The corollary to that is that we may want to integrate with solutions to adjacent problems. It is especially important to apply the pareto principle before starting work on integrations with other products.
Integrations can be a big time sink and so it is important to look at which 20% of software solutions are used by 80% of your target market. There are many software solutions that have dominated their markets and market segments well – SalesForce for CRM, QuickBooks for SMB Accounting. If you are building a time tracking tool for small service firms, integrating with QuickBooks for invoicing would be an easy decision.
Where this becomes a challenge is in cases where there are too many solutions to integrate with. One example would be building a product roadmap tool. It would be great to integrate a roadmap tool with existing project management and task tracking tools. There are so many project management tools – Jira, Asana, Trello, Monday just to name a few. One way to prioritize this list would be to address a specific market that is more likely to use one tool over the others. Small companies and teams may be using Trello, but large software organizations are likely to use Jira. In this case specific integrations should be prioritized that align with your ideal customer profile.
5. Don’t Rebuild a Competitor’s Product
If you are running evaluations with customers that have or are aware of your competitor’s product, any feedback about features that are missing should be taken with a grain of salt. Many times in a bake off, the features your product is missing are features that are in the competitor’s product. Sometimes these features should be built to achieve parity in an important area. However, implementing these suggestions blindly can result in a copy cat product. The goal is to be 10x better, not 10% better.
Markets do get competitive and having a similar product to a competitor is inevitable. At this stage it is important to focus on the strengths of the product and using those strengths to differentiate the product in the market.
Takeaways
When building a new software product, it is especially important to follow the unix philosophy of doing one thing and doing it well. A helpful exercise in keeping the problem space small is to look at the software ecosystem of your ideal customer profile (ICP). This exercise will make it clear which adjacent problems should not be solved by the product. This will also highlight which other software your product should integrate with. When integrating with products, avoid the long tail of integrations that could be a time sink for engineering teams.
Navigating feedback from customers is an important skill for product engineering teams to hone. In the early days, the sample set of customer feedback is small. The first step is understanding the problem the customer is bringing (not their solution). Dig into the size of the problem and determine if other customers are facing similar challenges. It could simply be a feature requested to check a box in a bake-off with a competitor’s product.
There is still so much software to be built that it is easy to design products with large scopes and ambition. The primary skill that any product engineering team needs is to keep focus on solving a single problem to the best of their ability.
“A sharp knife cuts deep”
– Kanwal Rekhi
