Last year I was thinking about the relationship between product effort and product value to try an answer a few questions like:

How much effort would feature X require? Is this feature worth the effort? What is hampering us from building this feature quickly to deliver that customer value? Etc.

So I started white-boarding, and I came up with this concept.

This is meant to be a framework to think about how products are built and for it to be a conversation piece for product and engineering teams to use for product planning. Typically, to build any amount of customer value, there’s a certain amount of development effort needed. When I say development effort I mean both design and development effort.

Usually there are diminishing returns to the customer value as more development is done. (more explained later)

Customer value really has to do with the expectations they have about your solution solving their problem or improving their lives. The expectation of value they have is influenced by, more often than not, things outside of your control.

To understand this graph better, anything that can be achieved above the line is delightful, because it’s low effort and high value. Anything bellow the line is riddled with plight, because it would require a high level of effort but would return little value for customers.

It’s extremely important to understand the dynamics and factors that will influence the graph.

Customer value expectations can be influenced from a number of things like:

• Functional & Technical expectations set by sales/marketing.
• ROI/Economic expectations of what they product can deliver.
• Competitors setting expectations in the market.
• Market trends.
• Customers’ own imagination (usually the case in new or nascent technologies like general AI, cryptocurrencies, blockchain or Web 3.0).
• Reviews and testimonials by other customers.

Engineering effort is also influenced by a number of other factors:

• Code base size and complexity.
• System architecture.
• Complexity of functional requirements set by product.
• Tech stack choice: building a web application in Django vs C++ is definitely a big difference in effort.
• Talent experience and team size.
• Existing customers dependent on existing feature/functionality: try changing an API that a large enterprise customer has baked into their world.
• Bugs and functional/technical gaps.

All of the above factors create complex dynamics that will influence your ability to build a product. You can see that there are a lot of things that you can and can’t control. It’s extremely important to understand these factors to see what levers you can pull or things you can influence when analyzing your own product/feature.

Investment Gap

Every new initiative (product or feature) requires a certain amount of effort before realizing the minimum customer value. The example of this would be building an authentication system for your social media app. The authentication system does product customer value because it protects the user’s data, but it’s not enough value to meet the minimum customer value expectations of what a social media system does.

This investment gap needs to be managed very carefully as it can require a significant investment, and is something that isn’t immediately sell-able to customers before the product can meet the minimum customer value expectation. Over investing too much in areas that are outside of the core value driver can be a waste of time and effort.

Now, let’s take a look at a few scenarios and examples to understand the framework even more.

The nightmare scenario for every company would be this:

The worst case scenario would be a product or feature that would require a high level of development that doesn’t meet minimum customer value. This is very common in nascent technologies like general AI, or human like androids. As of today, it would take a huge amount of investment to produce anything that would satisfy the general consumer market. If you look at customer expectations, something like androids should surpass the Uncanny Valley. This customer expectation is difficult to overcome or hack because it’s deeply rooted in our subconscious. In addition, we do not have the full range of technologies that can come together to product something that is realistic. It would require the machine to have a more advanced grasp of verbal and non-verbal communication.

The dream of every company would be this:

Low effort to release something that generates a huge level of customer value. Any incremental level of effort leads to a bigger jump in customer value. This rarely happens, and if it does it would be in niche markets with little good solutions. These solutions usually expose an arbitrage in space where customer needs are not met.The arbitrage quickly vanishes once more people know about this because it becomes a race to who can create the most value, and customer value line shifts up constantly where more effort is needed to generate value.

Take for example Tesla. Producing a new gas car and car company requires a huge amount of investment, engineering and strength to compete in a very competitive market. However, Tesla was able to tap into the unmet needs of customers that wanted a sexy electric car. Producing an electric car is simpler and requires less engineering effort because there are less components, and customers didn’t have any serious alternatives to pick from.

How can the line change?

Changing Customer Expectations

Customer expectations can change over time for a number of reasons. It could be that your competition has done something to change customer’s perceptions about their product and your product.

The real danger here is when customer expectations of value shift beyond the company’s ability to achieve that expectation. Let’s take the introduction of the iPhone in 2007 as an example. The iPhone coming into the market shifted customer expectations of what they’re looking for in a phone. This left dominant leaders like Blackberry in a serious execution gap to meet these expectations. It was years before Blackberry was even on par with what their competitors were able to achieve, but it was too late.

What to do when customer expectations rise?

It’s important to understand what are the causes of shifting customer expectations. Often times it is due to highly competitive environments changing customer perception.

• Marketing can play a huge rule here in differentiating your product and solution from your competitors. Look at Lufthansa and it’s competition with the low cost carriers. Rather than competing with them on price, they competed on quality, and comfort.
• Acquiring other solutions from the market that can be added to your offering to meet those rising expectations. In the same example Lufthansa acquired Air Berlin to directly compete with the low cost carriers, without needing to change their own company’s marketing and service strategy.
• This usually requires you to have enough flexibility in product and development effort to move quickly enough to meet the rising customer expectations.
• If there is little flexibility in development effort, then you’ll have to either find other value drivers that can overshadow this deficiency or to invest into changing the factors that influence the development effort.

Changing Engineering Effort

Throwing talent at the problem

What can bend the curve?

• Re-architecting the system
• Rewriting inefficient parts of the codebase
• Deprecating features that are not well used
• Remove dependency from customers on a particular feature that needs change.
• Leveraging a new technology stack that enables you to do more. For example Django is great MVC to use because it comes out of the box with a lot of things.

Investment Gap:

Thanks to: Faraz K, Nish and Johel D.

One of the things I struggle with most junior and senior colleagues is their inability to work with the unknown. It seems that many people expect that everything has to be laid out and there are no unknowns. However, as people progress in their careers they amass experiences, recognize patterns in the world, and become domain experts. Great colleagues who reach this stage are able to work with the unknown.

To progress your career and be a leader, be comfortable with the unknown. Leaders I respect and enjoy working with can take a single sentence or question, and can expand on it considerably. Their ability to fill in the gaps in what was said and not said during a conversation, meeting or email chain is one of the traits that makes them so great at their jobs. They’re able to do this by leveraging a huge pool of experiences (data), that they’ve boiled into thoughts (information), that get abstracted to insights (knowledge), to allow them to work with the unknown (wisdom) much more accurately.

Over the last while, I’ve been reflecting on what makes a great product manager (PM). Part of it is to hone my craft, and the other part of it is coaching others in their PM or startup journey. I also recommend these traits to founders of companies who are acting as product managers. This is a list of what I believe are a few traits that make certain product managers great.

Playing chess and checkers

It’s always the same story, we have 100 things to build and not enough time/resources. Savvy PMs prioritize and play chess. It’s important to mindfully think about how to structure a roadmap that can generate value while keeping building under-control. It’s extremely important to have a clear vision and strategy set for the product and to work with engineering to execute against it. I believe that a PM’s role is to mindfully design and manically execute. Execution is a game of checkers.

This will lead to not everyone getting what they want, so I want to leave you with this quote:

You can please some of the people all of the time, you can please all of the people some of the time, but you can’t please all of the people all of the time.

Jon Lydgate

Opinionated but not stubborn

Opinionated PMs can either be the life of the product or its death. Great PMs are opinionated and form their opinions based on facts like market data, sales data, customer usage data, speaking with customers, and so on. Terrible PMs form their opinions based on what they’ve heard, imagined, or feel. Even more dangerous is when a PM’s ego comes in the way and they become stubborn. Not adapting to new evidence is detrimental to a product.

Opinionated PMs should be able to talk about the product, problems, and features at any level of clarity, while also listening to ever-evolving needs and market changes.

Be steadfast in your mission, and flexible in your approach.

Be technical… enough.

A large part of a PM’s day is working and supporting the development effort. Understanding how your tech stack works & doesn’t can play a huge role in how you execute. PMs need to be comfortable with how their product is architected, modeled, built, and provisioned. I’ve always felt not understanding some of these elements leaves a PM blind and a developer alone in figuring things out. On the flip side, great developers need to understand how the product should functionally work, so why shouldn’t a PM understand how the technology works. I’ve often seen PMs say “not my problem, let the technical folks figure it out.” It’s a lazy approach.

We’ve been exploring React on our team, and so I spent a weekend learning React. Why? It’ll help me understand what they’re talking about, and to find ways we can leverage the technology to achieve more. So take an SQL course, or learn about the programming language your engineers are using.

Know when to lead and when to support

You often hear that the Product Manager is the “CEO of the product”. Product Managers lead initiatives across the board, but they’re not responsible for everything. Probably 80% of a PM’s time is actually supporting others to accomplish their goals. Helping clear up developer questions, supporting a marketing initiative, or even working with finance on metrics. Oftentimes, they find themselves needing to connect the different parts of the company. They need to be a communications hub cutting across all departments to enable knowledge sharing. Not only that, but they also need to be a translator to the different stakeholders. Lead in direction and design; support others in their success.

Negotiate together

The best PMs are masters at negotiating. You often find yourself negotiating features with customers, resources with engineering, designs with architects, etc. Negotiation sometimes feels like a dirty word because it’s often done as a contest of wills. A great PM focuses on real win-win situations for all stakeholders by understanding their interests without compromising on the product’s strategy and goals. This skill is something I recently realized I needed to work on.

Two books I can recommend are:

• Getting to Yes: Negotiating Agreement Without Giving In by Roger Fisher, William L. Ury, et al.
• Never Split the Difference: Negotiating as if Your Life Depended on It by Chris Voss

Conclusion

This is a handful of skills that I believe great PMs are made from. It’s not an exhaustive list, but having these probably will put you at the top of your game. Let me know what other items I’ve missed or if you agree with any of the items.

This was a blog post that I wrote for Coupa:

Every company faces certain risks to their business, and every company has a culture around how they address them. While official responsibility for managing risk rests with executive leadership, and in large companies, a dedicated risk management function, the company’s risk culture often forms unintentionally, based on how these people behave.

Read more on Coupa.com