Product management, new ideas - often ignored corner cases

Many of you would have read books or articles on product management (PM). A consistent message in PM literature is that products are built to solve customers problems. The product roadmap, prioritisation, etc. should be aligned with customer needs. It's important to speak to customers regularly and be in-synch with their problems/pain areas. Following these basic tenets would help the PM and tech teams build products that customers want to use/buy. 

The above message seems logical and pragmatic. But is there more to this? Have PM books/ articles missed a few corner cases?

A few cases that come to mind are:

• Do customers always know the problems they are facing? Do they care about their problems? 
• If the customer problem involves several external and internal entities, where does one start? Isn't the MVP going to be difficult?
• Does one only take up new or unsolved problems?
• How do PM teams of mature products(like Windows 10, Gmail) spend their time?

Lets go over these cases and see ways they can be dealt with. 

Do customers always know the problems they are facing? Do they care about their problems? 

(Sample problems: online grocery - pre pandemic , moving from cash to digital channels, moving from using excel to an online system for operations, etc)

Clients are so used to working in a particular mode/fashion they are reluctant to change. In a highly profitable business, even senior management can be reluctant to disturb a smooth but inefficient way of running operations.  In the product discovery phase one can get conflicting data in such situations. It's an inflection point - does one drop the whole product idea or should one go ahead and face the additional  challenge of changing a mindset. To an extent it depends on one's personality. Some of the factors to consider in going ahead with product development are: 

• Are senior management (non- direct users, buyer/decision maker persona) able to relate to the product value proposition? (Even if it's a 'Yes' the problem doesn't go away as they may not champion the product despite the benefits)
• How convinced are you about the value proposition ? Have you consulted domain experts/industry veterans on the problem you are solving? Do they believe that it can bring about change?
• Do you have the energy and patience to fight a long battle to change mindsets? Winning the first few clients can be a drag. Persistence and conviction is critical to cross that initial hump. 
• Is the reward worth the risk? Will customer perceive the big savings or optimisations delivered by the product? Are the potential earnings from product sales remunerative? 
• Is the target market size big? Once you are able to convince a few clients to buy/use your tool, competitors will enter the space.  

If you have a positive answer to the questions above and you feel it in your "gut", it's probably worth pursuing the product idea. The first few versions of the product may not have sufficient user inputs in product design, but that's okay. 

If the customer problem involves several external and internal entities, where does one start? Isn't the first few MVPs going to be difficult ?

(sample problems - marketplace (closed or open), manufacturing flows, hub operations, etc)

Even when a product is being rolled out for a small homogenous user base, initially it's a challenge to get all the stakeholders on the platform. To add to the existing issues, if the number of entities (including external ones) to deal with are more, the complexity of product roll-out and its successful usage is much harder. A few things to consider:

 

• If there are informational and transactional aspects to the product, one can start with the informational parts. The transactional aspects could be done manually by staff. E.g. if its a multi-party marketplace, a multi-entity portal can be built that shows prices that brings in transparency. The price discovery process itself can be a back-end manual process.
• In the product functional design assume some entities will not be using the system consistently in the early stages and device strategies around these scenarios. 
• Look for opportunities to help entities with bits of their daily work (for e.g. if they aren't using the system can you use it on their behalf, they can give their instructions on phone or email). This indirectly gives the PM team a good sense of the user requirements and the opportunity to build a better product. 
• Only if and when all entities use the product or service the product buyer gets all the benefits. To achieve this you may have to help the primary product buyer build traction. Leaving things completely on the buyer will result in him/her failing on the product roll-out and eventually backing out. The buyer will blame the complexity of the product or give some other reason for  stopping the product subscription. It's not uncommon to proxy product usage on behalf of the entities in the first few iterations to simulate traction on the platform.
• It's important to keep a log of the learnings, sequence of activities, etc., tracked well so that new client or new use-case roll-outs become easier, faster and simpler. 

The first few versions of the MVP is likely to be a low tech manual product. The focus is about solving the problem of the various entities and not about having an optimised end-2-end solution.  As the product experiments succeed, user acceptance and product usage goes up you can start working on tech automation and optimisation.

Does one only take up new or unsolved problems? 

It is nice to operate in a space in which one is a pioneer, but then that's a limited space which one may never figure out.  Building a product in a market in which alternatives are already available is okay, provided one has their own unique story as perceivable by the buyer.   A unique story could be in various forms, some of them are: 

• The ability to price the product at a lower cost with comparable features as competitors. 
• One has identified client segments that aren't covered by existing players.
• The existing products available are either over servicing  (basically an overkill for many client types and priced high for them) or under servicing ( the client expects the product to have modules "a, b, c, d, e" bundled in a single unit, but most products have only some of the modules.  
• The solutions designed by your product is unique and has a different flavour to what's available.
• A market survey done by you shows clients aren't happy with the existing products (because of service quality, usability, etc.).  
• The size of the market is so big that it can easily support many players.  

Basically one shouldn't enter a market with other competitors or products, unless one has clarity on why one is entering the space and how can one differentiate from the rest.

How do PMs of mature products (like Gmail, Windows 10) spend their time?

This case is the opposite to the other ones. They were mostly related to the start of the product journey while this is more about a situation deep in the journey many years into it. Mature products are ones which have solved most of the known user problems and there is little opportunity to further enhance the product in its current form/shape. A few things to keep in mind in such cases are:

• Don't change for change sake, it's better to stick to the paradigm "if it ain't broke don't fix it".
• New product releases may become infrequent and insipid, but that's okay.  Don't give into temptations to add unnecessary features.
• Customers are familiar and are comfortable to a style of working. So any big product change should also bring in a big jump in benefits. Otherwise it will make users unhappy and they will question the changes or even stop using the product.
• PM work can involve competitor analysis (to see if they have added any compelling features to their product) and thinking of lateral use cases(not directly related to the main product but has a lot of synergy e.g adding Chat, Ticket management modules to a CRM product) which could be blended into the product. 
• One can focus on the non-functional aspects of the product like speed/performance, feature availability across devices, etc. This includes removing outdated modules which aren't being used or are no-longer relevant.

There could be many more scenarios where its a tenuous line between the customer, customer's problem and PM. While the path to navigate this would require creativity, the outcomes of building products that solves customer problems and products that the customer is willing to pay for remains the same.

Senthil Radhakrishnan