TL;DR: Domain fidelity is a critical aspect of software development that ensures a system or product closely aligns with the real-world needs of its users. By prioritizing domain fidelity and avoiding the pitfalls of premature optimization, development teams can reduce technical debt and create more effective solutions. The key is to focus on understanding and accurately representing the real-world domain, while embracing simplicity and pragmatism in all stages of development. This approach sets the stage for long-term success and the creation of products that deliver genuine value.

Share

Introduction

Imagine launching a revolutionary software product, only to watch it fail spectacularly due to a fundamental mismatch between the system's architecture and the real-world problem it was designed to solve. A nightmare scenario for any development team, yet one that is all too common in the high-stakes world of software development. The culprit? A lack of domain fidelity, a crucial but often overlooked aspect of the development process, can doom a software company to failure when they might otherwise be a rocket toward the elusive unicorn status.

In this article, we'll dive deep deep into the world of domain fidelity and its strategic importance in preventing technical debt and ensuring long-term product success. We'll discuss the risks of premature optimization, uncover strategies for achieving high domain fidelity, and learn from the Google's missteps while launching Wave to illustrate the perils of low domain fidelity and premature optimization. Buckle up and prepare to navigate the treacherous waters of software development, where domain fidelity is your North Star guiding you toward success.

Defining Domain Fidelity: Aligning Systems with the Domain

Before diving into the risks of premature optimization and the importance of prioritizing domain fidelity, it's essential to define what domain fidelity actually means. In the context of software development, domain fidelity refers to the extent to which a software product accurately reflects the real-world processes, rules, and requirements of the problem domain.

Achieving high domain fidelity is a critical aspect of developing any product as it ensures that the system or product closely aligns with the real-world needs of its users. This alignment not only makes the product more effective and efficient but also helps to minimize technical debt, as it reduces the likelihood of needing to make costly and time-consuming adjustments to the system down the line. By prioritizing domain fidelity, development teams can ensure that their products remain relevant and functional over time, even as the problem domain evolves and user needs change.

With a clear understanding of domain fidelity and its importance in the software development process, we can now explore the risks associated with premature optimization and over-engineering along with the strategies for achieving high domain fidelity in more detail.

Subscribe now

The Pitfalls of Premature Optimization: Embracing Simplicity for Long-Term Success

While the nirvana for any software engineer is the perfectly designed system, focusing too much on building a "perfect" or "scalable" system early in the product lifecycle can actually backfire, leading to unforeseen technical debt. While this may seem counterintuitive, the primary driver of this explosion is when development teams invest heavily in creating a technically beautiful and scalable system without first testing its alignment with the real-world domain model.

In such cases, it becomes challenging to convince business partners to revisit and rebuild a system that was costly to develop in the first place. The result? A form of technical debt that arises not from the usual suspects – low-quality or hacky code – but rather from a mismatch between the system's architecture and the real-world domain it was intended to address.

A more effective approach in the early stages of the product lifecycle (both for new features and the product as a whole) is to create a simple, "quick and crude" version of the product that focuses on solving the real-world problem. This approach allows development teams to test and validate domain fidelity early on, ensuring that their system's architecture is grounded in the actual needs and requirements of the problem domain.

By prioritizing domain fidelity and embracing simplicity throughout in the development process, teams can reduce the risk of technical debt and create a strong foundation for long-term success. As the product evolves and its alignment with the real-world domain model is confirmed, teams can then invest in optimizing and scaling the system, confident in the knowledge that their efforts will be aligned with user needs and business goals.

The Google Wave Misstep: A Cautionary Tale of Overly Complex Technical Systems

Google Wave serves as an instructive example of a company committing to an overly complicated technical system without first testing and validating the design. Instead of prioritizing domain fidelity, the team prioritized future possibilities which ultimately led to the product's failure and the need for a revised approach (getting out over your ski tips as some would call it).

Launched in 2009, Google Wave was a real-time collaborative communication platform that aimed to revolutionize collaborative work. It integrated various forms of communication, such as email, instant messaging, and document collaboration, into a single tool. The ambitious feature set necessitated a complex backend architecture to support seamless, real-time synchronization.

However, the premature optimization of this technical system proved to be Google Wave's downfall:

1. Confusing user experience: The complex backend architecture translated into an overly complicated interface that users found difficult to navigate. As a result, many potential users (especially business decision makers) were deterred from adopting the platform.

2. Limited third-party developer support: The intricate architecture made it challenging for third-party developers to create compatible applications and extensions. Despite the existence of a plugin system, the complexity deterred many developers from spending time to build a robust ecosystem of add-ons and integrations.

3. Misaligned priorities: Google Wave's development team focused heavily on creating a cutting-edge technical system but did not adequately consider whether the platform's complexity aligned with users' needs and expectations.

In response to the platform's shortcomings and lackluster adoption, Google decided to discontinue Google Wave in 2010. The company later repurposed some of the technology into more focused and simplified products like Google Docs and Google Hangouts, which achieved greater success due to their streamlined nature and clearer use cases.

Subscribe now

Embracing Domain Fidelity as a North Star for Development Success

As we've seen throughout this exploration of domain fidelity and its strategic importance in software development, prioritizing the accurate representation of real-world needs, processes, and requirements is crucial to minimizing technical debt and ensuring long-term success. In the race to create technologically advanced and scalable solutions, it can be tempting to lose sight of the real-world context in which our products operate. However, as the cautionary tale of the Google Wave illustrates, this oversight can lead to disastrous consequences.

So, what can we as product managers (and developers and stakeholders), take away from this?

First, we must ensure that domain fidelity is at the heart of our development lifecycle from the very beginning. By focusing on understanding and accurately representing the real-world domain, we can create products that genuinely address the needs and requirements of our users.

Second, we must resist the urge to prematurely optimize or over-engineer our solutions. Instead embracing simplicity and pragmatism in all stages of development, refining and scaling our systems only after validating their alignment with the real-world domain model.

By keeping these principles in mind and treating domain fidelity as our North Star, we can navigate the treacherous waters of software development with greater confidence, knowing that our efforts are directed towards creating products that deliver genuine value and stand the test of time. In doing so, we'll not only minimize technical debt but also maximize the impact of our work, creating solutions that truly make a difference.

Share Product Solving by Tyler Wince

Share

I am intending to share the results of the survey from two weeks ago next Wednesday and announce some plans for Product Solving moving forward. Make sure you are subscribed so you don’t miss out!

Subscribe now

The main goal you have in building a product is to reduce friction from a process/problem your users currently experience. You aim to improve their lives. You unlock the ability to do things that were not possible without your products. This level of removing friction doesn’t happen accidentally. Your entire job as a product manager is to make impossible things, possible.

Hiten Shah said it nicely on Twitter recently:

Building products is, indeed, all about friction.

During the discovery phase you are identifying points of friction by talking to customers and finding out what parts of their workflow sucks.
During the design phase you are highlighting points of friction by creating mockups and design specs that showcase the new, frictionless workflow.
During the building phase you are testing the removal of friction by getting users to test your product and provide feedback.

Then the cycle starts over again as you interview customers who are using your products in their day-to-day work.

I was thinking about how this applied to my products and two questions came to mind:

1. What is product friction, really?

2. Is it possible to remove too much friction from a product? What happens if you do? (Spoiler: You can definitely remove too much friction, and your users are the ones who will suffer because of it.)

What really is product friction?

The best definition I have seen for product friction comes from an essay by Sachin Rekhi called The Hierarchy of User Friction.

“[Product Friction is] anything that prevents a user from accomplishing a goal in your product.” — Sachin Rekhi

In his essay, Sachin lays out the three main types of product friction: interaction friction, cognitive friction, and emotional friction.

Image Credit: Sachin Rekhi

Understanding these three types of friction is paramount to identifying and reasoning about what the right amount of friction is for your product, and when removing more friction would actually hurt your users.

You should definitely read Sachin’s post in full. He dives deep into why these are the three categories of friction and how they apply to building products, but, for now, a working definition of each will suffice:

Interaction Friction: Friction a user experiences when interacting with your product's interface. This type of friction is centered around the UI provided by your product. This could be a GUI, an API, or a more tangible good. Whatever your users interface with to use your product falls into this category. While this is important, it is typically not the place people end up removing too much friction.

Cognitive Friction: Anything that increases the total amount of mental effort being using in working memory. Features or workflows that make your users think harder or longer about how to accomplish their goal fall into this category. This could easily be impacted by interaction friction, but doesn’t only include UI elements.

Emotional Friction: Emotions your users feel that prevent them from accomplishing their goal. This type of friction can be caused by your product, but many times this friction originates outside your product and it is your job to help alleviate it. Past experiences and the perception of others are main causes of emotional friction for your users.

Removing too much friction isn’t always a good thing

While removing all three types of friction is one of your primary jobs as a product manager, there can be too much of a good thing.

Removing too much friction from a product can have disastrous consequences. From hurting your users, to affecting other parts of your product, to collapse of an entire system, sometimes friction is what holds everything together.

Hurting User Safety

Your users want to accomplish their goal with your product is efficiently as possible, within reason. Most of your users are unlikely to offer up personal safety in exchange for any decrease in process friction.

Case Study: Robinhood

While you don’t want to optimize your product for the “lowest common denominator” or your least savvy user, you do want to make sure they can use your product safely.

Robinhood, a financial investments app, has significantly reduced the friction for buying and selling stocks, ETFs, and options. They have reduced it so much that you don’t even need to have a large sum of money to buy stock in your favorite companies because you can purchase fractional stocks.

The workflow is simple. Download the app. Sign up for an account. And viola! You are ready to start buying and selling. “Making your money work harder”, as the Robinhood slogan says.

People are raving about Robinhood. In fact, they just raised another large round of capital to continue removing friction from the process of investing. But the success stories aren’t the experience shared by everyone.

Investing money is risky. It isn’t responsible for everyone to participate. And you don’t want to encourage people to put money into something that could hurt them eventually. Unfortunately, the reduced friction created in the Robinhood app has enabled that exact type of behavior. Users are placing larger sums into riskier, option-based investments without understanding the volatility and risks. [This has caused many to lose almost everything they have].

Robinhood is doing a great thing in reducing the friction for people to invest. It helps level the playing field for everyone and that is a good thing. But they should also be equipping people to play the game. Leveling the field isn’t enough when the users who need your product don’t even understand the game at all. Balancing the removal of friction while protecting users from themselves isn’t always easy, but it is critical. Especially when the stakes are this high.

Case Study: Zoom

Users don’t always need protecting from themselves. Sometimes they need protecting from others.

Zoom has taken the world by storm during the mass exodus from centralized office meeting rooms to decentralized, digital video calls. Zoom is the clear leader in the space.

One of the reasons Zoom has become so popular is their easy-to-use meeting client. You can join from your browser or the app. It takes one click to join the meeting. And even if you don’t have the link, the meeting ID is only 10 digits long. Zoom removed a huge amount of friction users experienced joining meetings on other platforms such as WebEx and GoToMeeting. They also simplified the in-meeting experience. Making the UI fast and responsive while eliminating the need to click in multiple different places to see attendees and the shared content.

All of this reduced friction introduced a problem as more businesses, schools, and courts started using it. People were guessing meeting IDs, joining meetings they weren't invited to, and “Zoom-Bombing” everything from corporate meetings to elementary classes. While sometimes innocuous, many of these events resulted in users of the Zoom platform being harmed emotionally.

As a response, Zoom has changed 2 key product defaults: 1) Requiring a meeting password that is embedded in the link and 2) forcing the meeting host to admit all users to the call explicitly. Both features add friction to the product, not eliminate it. And while it can be a pain, that is a good thing. Adding friction in key parts of the product likely wasn't on the roadmap for Zoom, but responding to issues and adding it in was the right decision.

Impacting other parts of your product

Sometimes you may want to introduce friction in one part of your product to remove friction from and highlight other parts of your product. While we like to see each feature independent of others, most of the time the friction removed in one feature can impact the friction in another. As a product manager, you have to decide which features are your highest value and most important. These should be as frictionless as possible even at the cost of increasing friction in another place.

Case Study: Apple and the App Store

Apple has been feeling the heat lately due to their handling of some high-profile apps and their removal from the app store. This has sparked a wave of conversation about the App Store, Apple themselves, and why they can maintain such a tight control on the only way to install apps onto the most common smartphone in the world.

This all goes back to the value proposition Apple is actually selling with the App Store: Ease and Security.

The App Store isn’t the only way to install apps on an iPhone because Apple wants to do all the extra work of verifying every app that could get installed on an iPhone. It also isn’t the only way to install apps on an iPhone because they want to take 30% of all In-App Purchase revenue (though it may seem like it). The main reason why you can only install apps on an iPhone through the App Store is because Apple is removing cognitive and emotional friction.

There once was a time when there were many app stores for Blackberry and Android devices. You would have to determine which was the most reputable, cross your fingers that the app was any good, and hope it wasn’t some piece of malware about to steal all your data once downloaded. This emotional and cognitive friction was a priority for Apple to remove.

The App Store removes all cognitive and emotional friction from installing an app on an iPhone. You know it will be safe, you know where you are getting it from, and you know what other users have said about the quality of the app. As a result, Apple has increased friction (significantly) in other areas.

It is nearly impossible to sideload apps onto an iPhone and you can’t install third-party app stores from the App Store. This means things like Xbox GamePass aren’t available on the iPhone. To Apple, this tradeoff is worth it. They would rather maintain a low level of friction in the areas they see are most valuable to the majority of users at the expense of friction for the minority.

The collective system can fail

Last, but definitely not least, the removal of friction can cause entire systems to fail. When products are used at a large enough scale, removing friction can cause some to take advantage of the product in a way that wasn’t originally intended.

Case Study: Credit Cards

When credit cards were first introduced, they were intended to enable shoppers to purchase goods or services for which they didn’t have the funds readily available. They intended to pay back the debt in a reasonable amount of time or risked paying even more than they would have otherwise due to interest.

Over time, credit cards became ubiquitous. Every bank gave out high-interest credit cards to anyone who asked, and they asked for very little in way of proof that you were willing to pay back your debt.

Every person felt entitled to buy things they couldn’t afford and it changed the way we thought about wealth and money. The amount of held debt expanded in the 90s and early 2000s as consumers continued to utilize credit to buy things they had no ability to repay, such as cars and homes. Until it all came tumbling down in 2008.

Each individual person thought they were only impacting themselves. Their decisions to consume more than they could repay wasn’t affecting anyone else and it wasn’t that big of a deal... so they thought. This is a classical tragedy of the commons. Every person thinking it is no big deal that they consume more than their share until the whole system breaks down due to everyone acting in their self-interest.

While most of our products aren’t as ubiquitous as credit cards, it is easy to see that the removal of too much friction from the process in obtaining credit as well as utilizing that credit can cause disastrous outcomes.

How to determine when to remove friction and when not to

There are 3 main ways I try to think about friction when making decisions about where to remove friction and where to introduce it: 1. Go back to your product goals, 2. Define your biggest differentiator, 3. Think like your users.

1. Go back to your product goals

Assuming you have your overall product vision and goals in place, you should be using these to determine priority of removing friction. You don’t want to run around with a proverbial machete, removing friction from everywhere in your users workflow. Instead, think of removing friction more like a surgeon, carefully cutting and removing to ensure a balance between removing the bad parts while optimizing the whole.

2. What is your differentiator?

Knowing what your biggest differentiator should help you find places that you want frictionless. This should also help you pinpoint where you need to be cautious in removing too much friction. Keeping the parts of your product that are your key differentiators in your mind as you carefully cut friction will ensure you don’t sabotage yourself by cutting in a place you shouldn’t. Think like the Apple team does when deciding how users get apps onto the iPhone. You have to ignore some feedback to keep your differentiator perfect.

3. Think like your users

There are 3 types you users you want to be able to channel:

- Your most knowledgeable user: These users know exactly how your product works and understand all the risks. They can handle some responsibility as long as it doesn’t compromise your next user...

- Your least knowledgeable user: This user has no idea what to do in your product and may get themselves in trouble. Don’t remove the friction so much that they miss the bumpers and fall into the gutter.

- A nefarious actor: What would happen if a bad actor could exploit your most frictionless feature? How would they do it? What would the result be? This can be hard to imagine, but trying to put yourself in these shoes can prevent lots of headaches downstream.

Eliminating friction from your product is critically important to building something users want. Most of the time, you want to focus on how you can remove as much friction from the product as possible. However, while you are working on removing product friction, be sure to keep in mind that not all parts of your product are created equal and sometimes removing friction can cause more harm than good.

What are some other examples of products that removed too much friction? Post them in the comments below and I will share them on Twitter!

Leave a comment

Subscribe now

"It isn't the customer's job to know what they want." - Steve Jobs

A couple months ago I wrote about the Problem Space and the Solution Space. The main idea of the article, if you haven't read it, is that product managers should be spending an unbalanced amount of time in the problem space. You are the one in the organization who has the opportunity to do so and you owe it to your team to do it well.

What does this have to do with customer interviews?

Knowing what your customer needs is squarely in the problem space. To wholly understand the problem space you must know your customers needs better than they know them.

But knowing your customers needs more than they do is impossible if you never talk to them.
Enter: customer interviews...

What are customer interviews?

Talking to your customers on a regular basis and calling it a customer interview is not enough. These conversations may help you come up with new ideas for the product and make your customers feel heard, but they aren't customer interviews. Talking to your customer without a clear goal is not a customer interview.

Customer interviews are a structured conversation with a specific goal in mind to help further the product vision and mission.

You will want your customer to be ready for the interview and know what you intend to talk about. Don’t blindside your customer, let them know you are wanting insights about your product and will come prepared to lead the conversation.

You are likely to learn a lot of different things while doing customer interviews. These include customer frustrations with their current workflow, new feature suggestions they want you to add to the product, and complaining about how your team doesn't get bugs squashed fast enough. All these things are great feedback to use when deciding what you should be working on next. However, not all the information is created equal.

How to interview a customer

There are dozens. of. articles. out. there. about. the. top. questions. to. ask. during. customer. interviews. This is not one of them.

You can have an amazing list of questions planned out and afterwards feel really good about your interview yet still accomplish nothing. You need a specific goal to accomplish in your interview to make it worth your while.

Go into every customer interview with a specific goal in mind and use the right type of interview framework to accomplish that goal. Don't let the customer take you down rabbit holes you don't want to travel. Help keep them on track by choosing a framework that suites the goals you have set out for the interview.

The important thing to remember when performing customer interviews is: don't reinvent the wheel. There are too many resources and frameworks out there to utilize. Find one that fits your needs and run with it.

Customer Interview Frameworks

Each of these frameworks illicit different types of feedback and accomplish different goals. You will want to pick which to use based on your relationship with the customer and what stage your product is in.

All products follow a basic pattern of "ideation/design" to "building" to "operation".

Ideation/Design is the phase before you have a product. You are likely building requirements, testing the market, and trying to figure out what to build.

Building follows ideation/design and includes all the time you spend working on the product until you launch it into production. I would consider any products that are in a limited "beta" release part of this stage.

Operation is when you have a product in production being used and depended upon by customers. This comes with its own challenges and needs that even products in public beta don't experience.

You should be talking to your customers during each of these phases, but your goals and informational needs will differ between them. While you can use any of these interviewing techniques and get some value from the interview, you shouldn't settle for "some value". Choose the framework that will get you the most value possible.

Subscribe now

1. Voice of the Customer

Optimum Phases: Ideation/Design, Operation

Goal: Create a prioritized list of customer wants and needs.

VoC Overview

Voice of the Customer can be a specific interviewing type and a goal in one. Listening and collecting the voice of the customer will make your product better in nearly every metric you measure.

Searching for the Voice of the Customer results in a detailed list of the customer wants and needs. Use this as an opportunity to look at your product from the eyes of another. They will highlight things you don't see.

You should leave this interview with 4 things:

1. A complete set of customer wants and needs

2. In the customers own words

3. Organized in a structural hierarchy by the customer

4. And prioritized by the customer by relative importance

VoC Resources

• VoC and JTBD Combined

• Simplicable.com Overview

• 4 Parts of the VoC

• 4 Tips for VoC Interviews

VoC Shortcomings

Don't let customer ideas be your only source for innovation. It is their job to tell you the challenges they have, it is your job to find an innovative solution. Sometimes customers will have innovative product ideas, but most of the time these are short-sighted and over-optimized for one type of user… them.

2. Jobs to be Done

Optimum Phases: Ideation/Design, Building

Goal: Create a job statement to align why customers hire your product.

JTBD Overview

The Jobs to be Done framework was popularized by Clay Christensen. The idea is that people "hire" products to complete a "job" for them. The best way to ingest this idea is to watch Clay himself explaining why morning commuters hire a milkshake.

When using the JTBD framework to interview, you don't want to focus on buying process, criteria, or anything else that distracts from the actual job needing completing. Your only goal is to gain a deep understanding of the job the customer is trying to get done.

A good job framework must:

• be stable, changing infrequently

• have no geographical boundaries

• is agnostic of the solution itself

• be a process

JTBD Resources

• Know Your Customers Jobs to be Done

• JTBD Website

• Great Images of JTBD Framework

• What is Jobs to be Done?

• JTBD and the Milkshake

JTBD Shortcomings

The JTBD framework can be too abstract. This can lead to your customer not articulating their job accurately and you getting misleading information. Make sure to ground the conversation in reality and always ask for examples.

3. Follow me Home

Optimum Phases: Operation

Goal: Understand how the user interacts with your product in their natural habitat.

FMH Overview

The Follow-Me-Home framework has been popularized by Intuit CFO, Neil Williams. Neil suggests the best way to get information about how your user interacts with your product is to meet them where they typically use it. This means getting out of your office, driving (or flying) to where your user is, and watching them complete their daily work. You learn things about their environment such as how many times they get distracted, who/what else is vying for their time, and when they abandon using your product.

When you allow the customer to interact with your brand and your product in their natural day-to-day work, you learn much more than you could in a simulated interview setting.

FMH Resources

• Intuit Business Insider Article

• Contextual Inquiry (Another Name for Follow Me Home)

FMH Shortcomings

It can be challenging to meet a customer and not interrupt their flow simply by observing. This is almost like observing wavelengths of light — they act one way when being observed and another when not. You should use this method with customers multiple times so they become comfortable with you watching over their shoulder. Explain to them you don't want any changes to the way they work so you get accurate information.

4. Focus Groups

Optimum Phases: Building, Operation

Goal: Collect quantitative data about user preferences.

Focus Groups Overview

Focus groups bring together about 6-12 people to test a product and gather quantitative feedback. These users are aware they are being watched and measured in how they interact with and experience the product. In some cases, users will assign measurements themselves on how much they like/dislike different parts of the product relative to others.

This method works great when A/B testing different mockups and prototypes to determine which route will provide the most benefit for the work required.

Focus Groups Resources

• Basic Overview

• Guide for running a focus group

Focus Groups Shortcomings

Focus groups typically require some other type of analysis or interview to have been completed previously. It is hard to perform a focus group without any product or mockup. Users also behave slightly differently and have different preferences when they are out of their normal environment (see Follow Me Home).

Subscribe now

5. SPIN

Optimum Phases: Ideation/Design

Goal: Narrow down the problem space to something customers will pay for.

SPIN Overview

Created by Neil Rackman in the 1970s, the SPIN method was initially built for optimizing the sale of an existing product. This framework also works great when interacting with users during the ideation and design phases. SPIN stands for situation, problem, implication, and need-payoff. Each of these steps provide a specific insight.

Situation: You are looking to get background information about the problem space and as much context as possible.

Problem: Explore what makes their job hard. What things do they see could be done better? Ask a user what parts of their job they dread and which parts make them dissatisfied.

Implication: You should find out what the negative consequences are for not fixing the problem. This could include lost time, money, or customer satisfaction.

Need-Payoff: Here you will determine what a customer would be willing to pay to fix the problem. You want to find out what the positive consequences are for solving this problem.

SPIN Resources

• ProvenModels Website

• Examples of SPIN questions

• How SPIN is used in selling

SPIN Shortcomings

SPIN is not a fully fleshed out framework for product building and customer interviews. Because of this, there are not many resources on how to conduct these types of interviews and what types of questions to ask at each stage. You will have to get a bit creative and put in the hard work to get this one moving.

6. The Four Helpful Lists

Optimum Phases: Ideation/Design, Building, Operation

Goal: Find product areas on which to focus additional efforts.

4HL Overview

This framework is not only helpful for product interviews, but also for optimizing processes and teams internally. It was created by Tom Paterson and is one of the simplest frameworks on our list.

On a board, create 4 main columns:

1. What's Right?

2. What's Wrong?

3. What's Confused?

4. What's Missing?

Each of these corresponds to an action you will want to take when building your product: Amplify, Fix, Clarify, and Add (accordingly). Users can add items to each of the four columns in any order and in any quantity. This can be relatively quick or take many hours with a lot of discussion.

This interview tactic is most effective when you are trying to understand what customers like, don't like, and want changed from their current state. This could be a new customer (not using your product) or it could be a long-time customer (using your product for years). This framework helps narrow down areas of focus across the product lifecycle.

4HL Resources

• Basic Overview

• Not quite product, but a good example

4HL Shortcomings

This framework is unlikely to get you very specific details about what a user is trying to accomplish and what their jobs are. You will need to follow up this interview with more specific interviews (such as Jobs to be Done) after you have narrowed your focus.

Just talk to your customers

Save this list for the next time you are about to do a customer interview. Identify the goal you are trying to accomplish, and use a framework to help you accomplish that goal.

All of these interview types will provide huge insights for your team and help you build something better than you would have otherwise. The most important thing is to talk to your customers as much as possible and optimize the format to match your goal.

When doing your interviews, remember what your ultimate goal is: live in the problem space and know it better than your customers know it. You should know their problems inside-out and upside-down. Only when you know their problem completely will you start to find the best solutions that even your customers wouldn't have thought of themselves.

What frameworks are missing from this list? Add your favorites to the comments below and I will share them out on Twitter!

Share

Introduction

Everyone wants to build a product that is “future-proof”. But what does building something “future-proof” really mean? Does it mean that it will seamlessly translate to the next technological revolution? That people will still be using it in 50 years? That it meets a persistent need that will never go away? 

These ideas are great ways to future-proof your product, but none of them matter if someone advances into your market and takes your customers. Your future-proofed product also means nothing if you can’t acquire users in a large enough market to stay relevant. As a product manager, your job is to ensure your product not only solves the customer's problem today, but that it makes your company money and maintains its viability for your users long into the future. 

Defining Your Market Space

One of the main things that must be done after a product manager has defined the problem space is to determine who the target market is, or define your market space. This step is critical to finding a problem that is both worth solving now and that will stick around for a while. 

Defining your market space is limiting your scope to a selected group of users that you can sell your product to. These are the people that you make user personas of and the people that have your sales team knocking on their door. Every successful company starts out with a small, niche market and grows from there. Companies and products that try to boil the ocean in their first iteration and go-to-market plan will fail. They will be everything to everybody and nothing to nobody. 

Instead, what you need to be is everything to somebody. Then you can grow into being everything for somebody+1, somebody+2, somebody+n. And if you start small, and grow your market space effectively, you will be the big dog and have the largest market share.

Why you need to start small: a short digression into business strategy

Peter Thiel famously coined the phrase “competition is for losers”. His main point is that competition, while valuable in determining that you have found something users want and is enough to take a bet on, will kill your company. You don’t want competition, you want a monopoly. 

The easiest way to get a monopoly is to build a product that is at the intersection of numerous things. Your user base is small, but in need and you can serve them with a product that they will love forever. Once you have dominated this market, you can start to scale. Envision concentric circles with an ever-growing market share as you expand. You start small and niche, grow large and dominant. 

This is where the idea of “escaping the competition” (also by Thiel) comes from. Your goal as a business should be to not have any competition. You want to have a monopoly on the market. 

Every small company, niche, and non-monopolistic will tell people they have a monopoly at the intersection of a handful of industries. Every monopolistic company will tell people they are not a monopoly because their business is the union of a handful of industries. Most large successful companies go through this transition in their company lifetime where they slide from small, niche, and non-monopolistic into something large, successful, and monopolistic. 

Understanding the Market Space

Once you have defined your market landscape (who you are going to sell to) you will need to make sure the product you build serves their needs better than anything else in the market. Two companies that have the same problem statement, but different market spaces will come up with a product that looks, feels, and behaves completely differently. In fact, many would think these companies are not even competitors in some cases because of the large differences in their products (think of the email apps Superhuman and Hey - case study on this is below). 

But this is only enough to get started. Once you have dominated the market space you have defined, you have to shed that exoskeleton and grow into a larger, more competitive one. This means moving out of your smaller concentric circle and into one that is larger and has more potential. However, more potential means more competition.

Your users here likely have the same problem, but their outlook on that problem may be different. You will need to do a combination of two things as a product manager: 1) sell them on your vision for the solution to the problem and 2) tweak your product to fill the gaps where you can’t. 

Selling them on your vision for the product

April Dunford has some of the best strategy and thinking around this. Your job is not only to sell the best solution in the market, but you also need to convince your users why your point of view is the best and how that inevitably makes your vision the best.

You need to tell a compelling story about why you are solving the problem in a way that the users want to experience it. 

Your point of view of the market gives customers a chance to walk in your shoes. You want to tell them why you prioritize certain features, who the optimal user of your product is, and why that combination will lead to a meaningful impact for them. Your users will have never purchased or used a product like yours, so you will end up spending a lot of time educating them. Give them your point of view, how it compares to your competitors, and why your point of view is better.

Fill the gaps in your product

Your new market is going to have needs that your previous market didn’t have. You should be looking ahead and anticipating these needs. Add some of the more critical ones to the product before you launch into the market or you won’t stand a chance. 

The best way to think about this is to think in terms of the Kano Model. The Kano Model tells us there are three kinds of features: necessary, expected, and surprising. You should begin market research to identify what types of features fall into each of these categories before you launch into your new market. Querying your future customers for insights on their workflow and problems will help you determine which features are necessary, expected, and surprising. Bucketing features in this way will help minimize feature bloat while ensuring your product meets the basic needs of your customers.

This does not mean you are going to do all of them, in fact, you shouldn’t. You are selling a vision that completely changes the way they work. Don’t compromise that vision because they tell you something is necessary. It may not be. But, you should do a few things:

Be sure you have all the necessary features baked. 

They just won’t use your product if you don’t. These are the types of features that provide a user the basic needs to do their job. Necessary features are like the wheels on a car, the product doesn’t work unless you have them.

As a product manager, you should be communicating with the business to determine what markets you are tackling next, begin doing your market research early, and get these things into the product. 

Have a surprising feature as well

If you add in a surprising feature, you will win over customers that you didn’t think would leave their current solution. You should do some competitive analysis to determine what features your competitors have and build something different. Don’t overlap on this one. Stand out, build something compelling, and win your users with this. 

Making the move

Once you have done this, you are ready to make the move into the next market space. You should ship early, often, and get as much feedback as possible. Your new customers will have complaints, and that is okay. Determine the right way to handle any complaints by separating the ones that are meaningful from the ones that aren’t aligned with your vision. A great way to do this is by using a product sieve, which I wrote about a few weeks ago.

Securing your monopoly for the long haul

It is easy and short-sighted to only look at current competitors in the market space you are moving into. The solution your target customers use today is definitely something that should be considered, but it is not enough to ensure you win. Remember, you don’t want part of the market share, you want a monopoly. 

As a product manager, what you need to be doing is researching other companies that are not yet competitors. These are companies that have the same problem space you have but a different market space and thus a different twist on the solution. They may have different corporate values due to the market space they entered into, and they will sell the product differently because of that. 

You should be looking at these “non-competitors” as your main competition for the future. They, too, are building their niche monopoly, growing into further concentric circles, and if you have the same problem space, your circles are going to overlap. This means that while you may not be competitors yet, you will be. And remember, you don’t want to have part of the market share, you want the monopoly. This means that one of you is going to win, and one will be left sucking wind wishing they had looked far enough ahead. 

Leaving your problem space and strategy open enough

I wrote recently about defining a product sieve, and how important that is for building a good product. This becomes critical when you start to see your job as something that needs to consider not only current markets, but future markets and the changing demands that may put onto your product.

You will have to make changes to the way your product delivers value. Don’t lock yourself into a single strategy that will force you to lose. You don’t want to be Blockbuster who didn’t move into the age of the internet with the right strategy. Winner takes all, and Netflix won. 

Subscribe now

Case Study: Blackberry and iPhone

Blackberry and iPhone were two completely different devices solving the same problem in completely different ways. They both started out to do “computer” activities away from your computer. For Blackberry, this meant things like sending emails and consuming basic parts of the internet. For the iPhone, this meant consuming content. One was work and the other was fun. 

The problem space was the same though — I need to do computer stuff away from my computer.

As the market space grew for iPhone and Blackberry, they began to compete. The iPhone started being more valuable for work, and Blackberry needed to find a way to keep up on content consumption. Unfortunately for Blackberry, we know how this ends... there is a reason I am writing half this post on an iPhone and not on an Evolve(?). 

iPhone left their product strategy open enough to handle the future concentric circles they moved into. They built a device that was touch-only when business people said it “wasn’t possible for a work device to not have a physical keyboard”. They built work applications like mail and calendar into the app when their current target market underutilized the apps. They were thinking forward into the next circle and what was needed. 

Blackberry on the other hand, added full-screen support later (remember the Blackberry Storm?...yikes). They were retrofitting their devices with features that were required for entry to the next circle, but they didn’t fit into their sieve. They realized they had started too well-defined and missed the opportunity. 

Case Study: Hey and Superhuman

Let’s look at a more recent case study that hasn’t panned out yet, Hey and Superhuman. 

Both apps have the same problem space. They both are solving for a default email experience that sucks where people want to get through their mail faster and in a more enjoyable way.  Both companies limit their target market out of the gate to only people who are willing to pay money (a lot of it) for a different default experience. However, within that, they both have different niches and target markets and thus, aren’t competitors... yet.

Superhuman is after the executive who spends the majority of their day in email. They have a GSuite account for work and need to find a faster way through their inbox. They get hundreds of emails a day, some valuable, some not. They need to identify which emails are actionable, which are informational, and which need responses. And they need to do it all right now. 

Hey on the other hand has a market of privacy-focused technologists. They don’t want to get through their email by using shortcuts, they want to get through it faster by getting less email. They don’t care about abandoning their email address for a nice, shiny @hey.com badge of tech nerdom. They just want email to be fun and relaxing, not stressful and anxiety-ridden. 

Two completely different apps, built for different experiences, workflows, and cost, solving the same underlying problem. Superhuman has done a good job of capturing a lot of the tech market in their niche. They have their small monopoly and are probably looking at what comes next. Hey, on the other hand, is still too new to determine if they will get that monopoly on their market. 

The real test for both apps will be how they respond to growing their market space. To continue growing their user base and their ARR, they will need to open up to a new target market. Doing this means they will soon find themselves competing. Superhuman needs to find a way to appeal to them more.

The goal for both companies should be to figure out where the concentric circles will connect. What market space they will be targeting when that happens, and to get started early by building features that start to draw that market in as early as possible. They both have something to learn from Apple and Blackberry... even if they start out with different market spaces, one of them is going to win and the other is going to Blackberry. Don’t be Blackberry. 

So what?

As a product person, you need to do the following things to keep ahead of the curve.

1. Dominate your current market space. None of the rest matters if you can’t do that.

2. Stay ahead of the needed features for your future market space. You just won’t get any users if you don’t have their needed features.

3. Work with your marketing team to sell the vision, not just the features. Every time you enter a new market, you will lose on features. Other companies have been there for longer than you and have more features than you. Win on the story and viewpoint of the problem.

Keep your eyes down-road. Don’t spend all your time looking in the rear-view mirror and miss where you are headed. Dominate your market, start building for the next, expand the market, and repeat. You will find yourself escaping competition by carving out your monopolies along the way. Keep moving from owning a monopoly on the intersection of industries to a monopoly on the union. 

Subscribe now

Subscribe now

It can be hard to define what makes a product manager successful. Their work speaks for itself, but putting your finger on what makes a great product manager successful and another fail can be challenging. 

The same thing can be said for businesses. What makes one business a success and another a failure isn’t always apparent. Great founders fail all the time.

Warren Buffett, Chairman and CEO of Berkshire Hathaway, has a model for this: the Institutional Imperative. This concept has changed the way he invests in companies and how he chooses which leaders to bet on.

The Institutional Imperative

In his 1990 letter to shareholders, Warren Buffett defined a term he had used in the previous years’ letter: 

Institutional Imperative, noun

“the tendency of executives to mindlessly imitate the behavior of their peers, no matter how foolish it may be to do so.” 

- Warren Buffett, 1990 Shareholder Letter

Buffett suggested that institutions tend to fall into four traps which he calls imperatives. These imperatives are the default behaviors at most organizations who are not actively resisting them.

Buffett’s own words explain the 4 imperatives best:

“(1) As if governed by Newton's First Law of Motion, an institution will resist any change in its current direction;

(2) Just as work expands to fill available time, corporate projects or acquisitions will materialize to soak up available funds;

(3) Any business craving of the leader, however foolish, will be quickly supported by detailed rate-of-return and strategic studies prepared by his troops; and 

(4) The behavior of peer companies, whether they are expanding, acquiring, setting executive compensation or whatever, will be mindlessly imitated.” 

- Warren Buffett, 1989 Shareholder Letter 

Jeff Bezos, CEO of Amazon, has shared a similar model in his shareholder letters. Bezos calls it management by proxy. By “proxy” he means systems put in place to better the organization and their ability to service customers. The problem arises when the systems become the primary focus. They lose their intended effect. Management by proxy results in people saying things like, “I followed the standard process” instead of taking responsibility when things don’t go according to plan. 

Having a clear understanding of the Institutional Imperative and management by proxy helps leaders in an organization see their blind spots and avoid traveling along the default path -- what all leaders would do if not proactively minimizing the effects of the imperative. 

The main argument made by both Buffett and Bezos is that leaders need to understand and actively work against these patterns in their business. Because they are so easy to fall into, most managers fall into these patterns by default, and don’t even realize they are doing it.

It is also important to highlight here that intelligence and experience have nothing to do with susceptibility to the imperative. Buffett says this was the biggest surprise he had when leaving business school -- some of the smartest and most experienced business people fall prey to the Institutional Imperative and are blind to its effects. This is why it is important to organize your business to minimize the effect of the imperative.

While institutions as a whole seem to fall prey to the institutional imperative, product teams seem to fall prey to a different, yet similar, set of imperatives. Gone unnoticed and uncorrected, these imperatives will result in products that fail. Building a product while trapped in an imperative feels like chasing your own tail -- you are constantly responding to the world around you instead of actively participating.

Let’s jump in…

Subscribe now

The Product Imperative

The Product Imperative inherits its core from the Institutional Imperative, but highlights the default tendencies of a product team rather than an organization as a whole. As with the Institutional Imperative, product managers need to build systems and structures to ensure they minimize the effects of the Product Imperative.

The Product Imperative, noun

The tendency of product managers to neglect the important and challenging parts of their job. Letting other people and processes do the important work for them. 

What I have noticed is that a product manager's ability to drive true innovation and build successful, competitive products shrivels when the product imperative comes into play. 

The main elements of the product imperative are the product manager’s tendency to 

1. have a one-track mind, only considering a few solutions,

2. looking through the rear-view mirror at prior success instead of through the windshield at the potential,

3. allow the product to be prioritized by majority rule,

4. assume product success equates to product-market fit,

5. assume busyness is a good excuse for not creating a strong vision and strategy, and

6. allow the process to dictate their ability to execute.

Each of these can be easily overcome by acknowledging their existence and organizing your work to minimize their effects.

1. One Track Mind

The product manager locks themself into a single way of thinking about their problem space, crushing any hope of adopting a potentially more elegant solution to the problem. As a side effect, the product manager will find all data necessary to back up their decision to shut down any potential dialogue around alternative viewpoints.

This is rooted in how our brains work. Once you see something, you can’t unsee it. Known as First Conclusion Bias, we end up blinding ourselves by filtering everything through the lens of our first conclusion. Charlie Munger, Buffett’s partner at Berkshire Hathaway, has compared this to the sperm and the egg: the egg locks out all other sperm after the first is in. Similarly, we get the first conclusion in our head and our mind locks anything else out. This isn’t always a bad thing and in many cases (specifically those where the decision being made is reversible) can be beneficial. But when we are trying to understand and solve novel problems in the product, we need to be able to see the problem without tainting our point of view. 

If the product is further along in the development cycle, this might also be considered the “Beautiful Baby Syndrome”. Every parent believes their baby is the cutest. Every creator believes their work is superior. And every product manager believes their product is perfect (or at least more so than it is). This is especially true when the product manager has owned the product since its inception, having worked tirelessly to build the product into something that is meaningful. Unfortunately, as the landscape changes, parts of a product become irrelevant and outdated. The product needs to be updated with the changing times. This requires deprecating or removing parts of the product that required blood, sweat, and tears to build.

Combat this imperative by trying to “see your problem with fresh eyes”. The easiest way to do this is by working backward from your end goal to redefine the problem. Doing this exercise is called inversion and it helps you see the problem in a new light. I wrote about how to apply inversion to product management a couple of months ago. 

2. Rear-View Mirror and the Windshield 

Resting on their laurels, the product manager sees prior success as a reason to not look forward. They see changes in the market or changes in technology as a burden rather than something that would help their product stay on the forefront.

When you are driving a car, the only way to stay on the road is by keeping your eyes down the road, where you are headed, and only occasionally looking in the rear-view mirror. Many product managers spend too much time looking in the rearview mirror, completely disabling their ability to steer their product down the right course. 

I wrote in my essay on leverage that it is a product manager’s job to put on guardrails and keep the team headed in the right direction. And though you can drive on a straight road while looking in the rear-view mirror, it is only a matter of time before changes in orientation come. By the time you have responded it is too little, too late. This is the same in product. You may continue to have success while looking through the rear-view mirror, but you won’t be able to adapt to changes in the market fast enough to stay on top. It is only a matter of time before you are off course and struggling to maintain relevance.

Combat this imperative by only using historical facing data with a grain of salt. Find people who are the best thinkers in your problem domain and follow their work. They will give you a good sense of where the domain is headed, and what the view looks like through the windshield. Keeping your eyes down the road will enable you to adapt quickly and efficiently to any industry changes.

3. Decision by Majority

Lacking any true knowledge of the territory in which their product is deployed, the product manager allows anyone and everyone else to make the decisions for what their product features should be. They turn to sales, marketing, customer success, and the customer themselves to dictate the product roadmap and what problems the product should be solving.

Hear me on this: these folks should all have input. They have territorial knowledge too and are essential voices in directing your product to success. But the person who knows the problem best should be the product manager. Their job is to look beyond the (sometimes) short-sighted suggestions of others and find the true problem to be solved.

Many other people in the business suffer from the tendency to overgeneralize from small sample sizes. They hear a problem in a sales call, maybe hear it twice, and it sticks in their mind because they were uncomfortable being unable to say, “Yes, our product does that”. And while this may be a useful problem to solve, the product manager should be using everything else they know about the industry to determine the long-term value of solving that problem. Solving too many of these niche problems leads to finding yourself stuck in a local maximum, potentially with too high of an activation energy to get out and move toward the global maximum.

Product Managers that allow their product to be driven by the majority tend to end up with a product that is trying to “keep up with the Joneses”, matching the features of their competitors. Instead of taking a unique view of the problem and selling why you are better to the market, you end up competing in a race to the bottom on how cheap you can sell your product.

Combat this imperative with your marketing team. Help them put together the position statement for your product rather than just a list of features. Your sales team will be equipped to tell the market why you decided to prioritize certain features and why your product is the best solution. Selling your point of view of the world instead of selling your list of features changes the way customers view your product and enables sales to sell more without constantly needing new features to close a deal.

4. Confirmation Bias

Using sales metrics as the only indicator that their product is successful and solving the right problems.

There are many products that customers would rather not use, but they are the best of what is available. Hiten Shah recently surveyed twitter to determine if Zoom (the video conferencing company) had product-market fit. Turns out, they don’t. Most people wouldn’t be upset if Zoom went away tomorrow.  But, they continue to purchase it for 2 reasons: 1) it is better than anything else available in the market right now, and 2) the customer (buyer) isn’t always the same as the user. 

The split in the buyer and user perspectives can lead to a product that demos well, has more features than any other product, and looks to be the best value. But the product ends up not being used because it doesn’t solve the actual problem. Adding feature after feature (feature bloat) just to pad the list of checkmarks in a product comparison chart doesn’t mean your product is good nor does it mean your product is solving the intended problem.

If you looked at the usage metrics of Zoom, you would only assume they have great product-market fit. Unfortunately for Zoom, their users don’t feel like they solve the problem any better than anyone else. 

Combat this imperative by looking at more than just product metrics. Product managers should be doing more than just looking at monthly active users, transaction rates, revenue targets, and new clients. These are all great indicators of a growing business and a sign that the product is doing something right. What these don’t mean is that the product is loved by your users and has product-market fit. Communicate with your customers and learn about why and how they use your product. You will learn a lot more that will guide where you take the product in the future.

5. Too Busy For My Job

A product manager who has no time for vision or strategy. They only have enough in the tank to execute what has been put before them. Falling prey to the business imperative pulls them like a black hole into all of the other imperatives.

Falling into this cycle will lead to a product that tries to advance on all fronts, doing everything under the sun and none of them well. The product manager will allow any decent opportunity to pivot the team, and ultimately leave most features half baked and useless. The product vision and strategy should be used by the product manager as a tool, used to determine what to say “no” to just as much as what to say “yes” to. Taking on too much will lead to an unusable product. 

“You can’t advance on all fronts in all directions” - Peter Thiel

Product managers need to be in command of their product, deciding what features are being included and how they are tracking success. Don’t enable yourself to get “too busy” doing day-to-day work that you lose sight of the direction you are headed.

Combat this imperative by making time for your vision and strategy. You must be the person to define your vision and strategy. There is no way around it and no shortcuts here.

6. That’s Not The Process

The product manager forces their agile methodology even when it doesn’t make sense just because that is what all the other teams do. They have no use for thinking long term because their sprints are only two weeks long. They throw their hands up in the air when the business asks for more predictability while maintaining the short release cycles.

This is something Bezos would call management by proxy. Letting the agile methodology get in the way of doing great work. Sometimes it makes sense to be more flexible; allowing the team to work in a more flexible rhythm. Sometimes it makes sense to do the opposite, drive discipline to the process to ensure something gets done. But at the end of the day, throwing up your hands and not allowing any changes simply because “That’s how we do things around here” makes everyone worse. 

Your job as a product manager is to inspire, lead, and lift the whole team. Make the people around you better. You can do that by listening to your team, being creative about how you provide the needed information to your stakeholders, and never letting a process manage your product for you. You are the product manager, not the Scrum process.

Combat this strategy by finding new ways to manage your stakeholders and the process you use in development. Listen to what your stakeholders are asking out of your team and the development teams, and use inversion to find a way to get you there. You will be lauded in the organization if you are actively looking for ways to meet the needs of your stakeholders while helping your development team partners stay focused on building.

So What Do We Do? 

Warren Buffett says one of the most important things he and Charlie do when investing in a company is to find founders who are aware of the institutional imperative. This awareness brings forth action and mitigation to ensure they don’t become prey.

Just as with the Institutional Imperative, even the most experienced and intelligent product managers fall into these traps. It is not stupidity or incompetence that leads us into the imperative, it is simply the default and most worn path. Look for places in your work where you might be blind to part of the imperative. Organize your work to mitigate the risks of the Product Imperative.

Both the Institutional Imperative and the Product Imperative are a bit of a misnomer. Imperative implies they are inevitable, inescapable, and certain. But that doesn’t have to be the case. Being aware of each of these imperatives is the first step toward avoiding the trap. Combat each imperative with a clear strategy and purpose: 

1) use inversion to see your problem with fresh eyes, 

2) look through the windshield by seeking out the best thinkers in your industry and letting them show you what’s coming, 

3) help your sales partners by enabling them to sell a point of view instead of a list of features, 

4) remember that metrics don’t mean everything, talk to your users, 

5) make your vision and strategy -- just do it, and 

6) manage your stakeholders and make the process you follow work for you, not the other way around.

Unlike a black hole, which has an inescapable pull, these imperatives are more like a treadmill. If you stop walking, or you trip, the treadmill will pull you back. Escaping the traps of the imperatives requires a constant effort. If you work against the default, find ways to structure your work, and keep yourself aware of the imperative, you can escape it. You have to constantly be working to not slip back into the default patterns of behavior. When you do slip, recognize it, identify what caused it, and move along with a new insight into how to avoid it in the future.

If you liked this post, click the heart and subscribe below for more product insights delivered to your inbox every Wednesday.

Subscribe now

Thank you to the Compound Writing members who reviewed this post: Stew Fortier, Padmini Pyapali, Richie Bonilla, Josh Mitchell, and Kevin Shiuan.

Follow Tyler on Twitter

Subscribe now

Image Credit: Leo Gao

For years, there have been warnings that AI is going to eliminate routine, manual jobs. While this hasn’t yet come to fruition, the mood about AI and job elimination seemed to change this past week. GPT-3, an AI model that performs next-word prediction, plastered Twitter feeds with examples of how AI could not only replace manual workers, but knowledge workers as well. 

I’m a skeptic. I don’t think AI will completely displace workers anytime soon. However, I also think there are valuable lessons in how AI models like GPT-3 generate novel content. These learnings can help us in our work now. AI such as GPT-3 may soon augment some of the product creation process, but the biggest help it provides is in showing us how to be better thinkers, and thus, build better products.

What is GPT-3?

The scientific paper describing GPT-3 was released back in June, and the API was made available in a limited, private beta this past week. And, for those of you who don’t spend all your time on Twitter, GPT-3 made waves with examples of how it could create websites from natural language, write product requirements based on a problem statement, and create novel tweets. 

GPT-3 is an AI model developed by OpenAI. It is the third generation of the Generative Pretrained Transformer (GPT) models. GPT models are a type of machine learning trained with a large, diverse corpus of text. These models are not given a variable to predict during training—as is the case with supervised machine learning models—and are used to predict the best next word given a section of text. Because the performance of these models is highly dependent on the amount of data consumed during the training phase, the team at OpenAI upped the training set two orders of magnitude between GPT-2 and GPT-3. The training corpus for GPT-3 is essentially the entirety of the open internet as of October 2019.

How does it work?

One important characteristic of GPT-3 is that it requires priming to work. Priming is when you expose someone (or something) to a specific stimulus that then results in the identification of other things that were previously unnoticed. Here’s an example:

Imagine you are in the market for a new car. You want to be original but not too flashy, so you start looking for a Volvo. You poke around on Carvana, Volvo.com, and a few other car sites before deciding on a model you like. You still don’t feel quite ready to buy, so you put it on the back burner and hop in the car to get lunch. On your way to the fast-food joint down the street, you notice the exact car you were just looking at online! “What a coincidence!” you think to yourself. “I never see any Volvos out on the road, let alone the exact model I was just looking at.” Throughout the rest of your trip, you notice four more Volvos. This makes you wonder if you were original at all by assuming a Volvo was a less-than-popular car. 

I am sure this has happened to you, if not a car then with something else. Nobody read your search history and bought a bunch of Volvos just to mess you with you. You just weren’t looking for them before. This is priming. Your initial stimulus was the decision that a Volvo is a fairly uncommon car so you looked at a few online. It’s only after this stimulus that you recognize there are more Volvos on the road than you thought (In fact, I bet the next time you are out driving on the road you will notice a Volvo. You’ve been primed by reading this example!).

Just like you need priming to recognize something you haven’t noticed before, GPT-3 needs priming to generate new content that hasn’t been seen before. The priming is done by providing a prompt as an input to the model. This could be the beginning part of an essay, a question, or even a partial block of code. All GPT-3 will do is determine what the best next word(s) is to complete your prompt and repeat that process until you tell it to stop.

Primers to Building

While GPT-3 is certainly an amazing step-change in the functionality of AI, it isn’t going to replace the generation of new product ideas anytime soon. The biggest reason is that it needs an effective primer to build anything novel. You need to see the world in a unique way to create a primer that generates a meaningful new insight. GPT-3 may become a very useful tool for product managers: changing how they write requirements, discover missing features, and validate new market opportunities. But above all, I believe it best serves as an example of how creating better primers helps us build better products.

The hardest phase of building any new product is making the decisions about novel features. These are the parts that are at the core of solving the customer’s problem. Often we try to do this by brainstorming with our colleagues. You stand next to a blank whiteboard, your colleagues staring back at you, waiting for someone to have an idea. When they finally say something, it seems fairly predictable, lacking any true ingenuity and creativity. Though this may be a common experience during brainstorming with others or by yourself, the thing that takes your decision making from mediocre to amazing is a good primer. 

There are some basic things we can learn about creating primers by studying the types of primers that result in quality GPT-3 outputs. Just like GPT-3 needs a primer to generate output, product managers need a primer to create novel and valuable solutions to their customer’s problems.

1. The Medium Of Your Primer Matters

For GPT-3 to generate a novel bit of code, it needs partially complete code as the primer. To generate an answer, a question must be the primer. The generated output will match the format of the primer.

Our minds work in the same way. Some of the world's best writers spend an inordinate amount of time reading. Reading is the same medium as writing (written language) and thus provides an effective primer to generating new ideas through writing. Reading not only helps you generate and realize new ideas to write about, but it also helps you become a better writer.

In the same way, artists paint scenes from the world around them. Their environment and the visual imagery they immerse themselves in inspires future works of art. 

So what type of medium should product managers consume if they want to build better products? It depends on the task. If you are trying to generate new ideas for how to display data on a webpage, scour the internet for dashboards and data formatting tools. Take note of how they display information and use that as inputs to your design.

If you are trying to create a completely new product idea, you should be looking at niche and novel products that uniquely solve other problems. When doing this, look at the ways the product solves the user's core problem. These nuggets of inspiration will get your mind primed for generating novel techniques to solve your user’s problems, even if it is a completely different domain.

Trying to convert from one medium to another adds cognitive load. Lower the activation energy of these new ideas by using a primer that matches the expected medium of your output.

2. Your Primer Should be Something Directional

But having a primer that matches the medium of your output isn’t enough. The primer must also direct your thinking around the specific problem you are trying to solve. Priming GPT-3 with something that is too open-ended and ambiguous results in aimless rambling unrelated to the user's intended output. And, you guessed it, our brains work similarly. This is why writer’s block exists. You are staring at a blank page, unsure of what to write because there are too many options for what could come next.

When trying to design a new website, you don’t want to start with a blank browser shell. This provides too little direction. Instead, collect examples of elements you think look nice, choose a color scheme, and decide on a set of basic needs. Creating this palate of ideas will help you create something more valuable because it provides enough direction to get you moving and enough ambiguity to allow your creativity to shine.

A highly effective way to provide directionality in your primer is to leave an idea incomplete, even if you think you know the best way to solve it. Leaving a problem half solved allows your mind to wander, thinking about all the possible ways to complete the half-baked solution. Because our minds don’t like the cognitive dissonance of an incomplete problem, it is forced to think of ways to solve it.

3. Consume the Output of Your Work as an Input to the Next

If you are creating a feature list of what your product can do, use each new feature as an input to the next. This is something that differentiates the human ability to generate unique and cohesive ideas from models such as GPT-3. GPT-3 cannot understand what the previous inputs mean, only that they are a collection of inputs to generate an output. When you are building a list of features, you can understand how one might impact another, or how a basic feature could inform more complex workflows downstream. 

The other thing humans can do that GPT-3 cannot is change the inputs. You can see how a design choice made previously acts as a poor primer to drive further development in other parts of the application. Changing the upstream design has large downstream consequences, both good and bad. Don’t be afraid to tinker with decisions that were made previously to see how they change the later outputs.

4. The Quality of Your Primer Matters

Writers don’t get better at writing by reading crappy books. Painters don’t get better at painting by looking at bland landscapes. Product Managers don’t get better at building products by studying boring solutions.

A primer that is both the appropriate medium and provides clear direction isn’t enough to ensure great output. The quality of the primer must also match the quality of the desired output. For product managers, this means studying highly creative and successful products (both niche and mainstream). 

Increasing the quality of your inputs also requires a wider breadth of industries as inspiration. If healthcare companies never lifted their head to look at how other industries were managing data, electronic medical records would not exist. You should take time to lift your head, look out at other industries that have a similar core problem to yours, and take inspiration from the products that are solving it best.

Low-quality primers lead to low-quality outputs. But the inverse is also true. Always ask yourself if you are using the highest quality primers for your own thinking. If not, search for where can the highest quality inspiration be found. Only use the best possible primers for your product, it is the easiest way to increase the quality of your output.

TL;DR: With GPT-3 or Without It

Models such as GPT-3 may have a profound impact on how we design, build, and create new products. The future is bright and the possibilities endless for how this type of model could be applied. Whether or not GPT-3 truly has the capability to replace some knowledge workers is yet to be proven. Though while the applications begin to appear, we should take advantage of how these models can generate so much novel content. Identifying what makes a great primer and applying that to the way we think and build could have a profound impact on our ability to create. 

Here’s how we can apply what makes GPT-3 great to our current product management style: 

1) The medium of your primer should match your expected output medium

2) Your primer should be directional

3) You should consume the output of your work as a primer to any future work

4) High-quality primers lead to high-quality outputs

However, as we learn more about these generative models and what makes them work most effectively, we should adapt ourselves. The things that make the best primers for GPT-3 also make great primers for us.

If you liked this post, hit the heart button, leave a comment, or subscribe below for more product insights delivered to your inbox every Wednesday.

Subscribe now

Thank you to Josh Mitchell and Ross Gordon for reviewing this post.

Subscribe now

This post is part 2 of a two-part series on the concept of a product sieve. If you haven’t read part 1, I would suggest you start there.

Part 1 explored the need for a product sieve. Our dislike of boredom and the chase of consistently performing at peak productivity result in building products that don’t solve a real problem. 

Part 2 is about application, answering questions such as:

• What are the features of a good sieve?

• How do I build a product sieve?

• Once my product sieve is created, how do I use it? 

These questions and everything in between lie ahead.

Characteristics of a Sieve

A sieve is a tool used to separate smaller chunks from larger chunks of material. Depending on the strength and the characteristics of the sieve, it can separate a wide variety of material. However, it is important to understand what your sieve can and cannot do.

What a Sieve Can Do

A sieve will tell you one critical thing: Does this material match what I am searching for? Physical sieves tell you whether or not the material is the right size and shape. Your product sieve will tell you which ideas are possible solutions and which aren’t worth your time. This is an important, if not the most important, part of building a product. Ideas are cheap, and building is expensive. Your sieve should let you play fast and loose with ideas in order to ensure you don’t waste time building something that doesn’t provide value.

A sieve has two main characteristics, the holes through which low quality material escapes, and the mesh pattern that catches higher quality material. Both of these play a critical role in your sieve, but you should only be focusing on one. The mesh. Don’t misunderstand, the holes are a critical part of your sieve. In fact, if you make the holes too small or too large the entire sieve, no matter how well built, is worthless. But it is the mesh that defines the holes, so focus solely on the mesh.

When you are using a sieve, the shape of the mesh (and thus the size of the holes) determines what it will capture, and what will escape. The mesh is what captures the high value ideas and what defines the holes that allow inexpensive and bad ideas to fall through. You want this to happen before the ideas become an expensive product feature to build.

What a Sieve Cannot Do

A sieve does not create the material that is passed through it. In the example from Part 1 — separating dirt from gold — your sieve creates neither the dirt nor the gold. These materials must come from elsewhere. Similarly, the ideas you pass through your product sieve must come from elsewhere. They could come from meetings with customers, your own research and brainstorming, or suggestions from your development team. Ideas come from all over the place (that is why we are building this sieve in the first place). But, the one place they will not come from is the sieve itself.

Also, a sieve does not prioritize the order through which you review its captured contents. When you pass material through the sieve, some portion of it will be captured. After that, it’s up to you to determine the order in which to further examine and process the captured material. This same principle applies to your product sieve. Your sieve will not tell you which ideas are more important, create higher value, or increase profits: That is your job. 

Subscribe now

How to Build a Sieve

Building a product sieve doesn’t happen in a single sitting. Your sieve will change over time and multiple people will have worked to build it. The good news is that some of the parts of your product sieve may already exist, you just need to leverage them in a new way. 

There are four main parts of a product sieve: 1) the problem statement, 2) a vision, 3) part of the plan to get there, and 4) questions to make it usable. 

The Problem Statement

This part of your sieve may already be complete, but it is surprising how many organizations and products skip or hurry through the problem definition stage. These products typically become “hammers in search of a nail” -- products that solve a problem nobody was asking to be solved. While you may already have a problem statement for your product, this is a good time to revisit it. 

Note: The problem statement is rarely a single sentence. While it can be that short, it is often helpful to wrap some background context around your problem statement.

The best problem statements typically get started with saying “It really sucks how...”. These four words help you define what your problem really is. Use this as a starting point to identify your problem statement. It will help you find something that is emotive, and that gets your team, and customers, to agree and say, “Yes, that does suck!”

The Vision

Show what the world could be like if your problem statement was no longer a problem. Your vision statement should be inspiring. Your problem just explained how something sucks, now is your chance to flip that narrative on its head. Your vision should be the answer to your problem statement: “Something in the world is wrong, and it sucks. But here is what the world could be if this was fixed”. The vision is what will keep your team motivated as you work hard to make the world a better place.

A Plan to Get There

Now the shaping of your product sieve really begins. The first two elements are critical for forming the landscape in which you will work and build, but the plan is how you are going to get there. The plan is what your product will do, how it will work, and why users find it delightful.

However, you don’t want to define your entire plan here, because then you wouldn’t need a product sieve. You would already know exactly how you are getting from the current world to the future one. The goal of your plan is not to define every feature or every piece of technology you will use. Rather, the goal of your plan is to start shaping the mesh on your sieve so you can filter the right amount of “dirt from gold”. 

This is more of an art than a science, but here are the general rules that apply when creating the plan: The more detailed your plan, the larger the holes in your mesh. Likewise, the less detailed your plan, the smaller the holes in your mesh. While this may seem counterintuitive at first, it is an important distinction, so let's break it down a bit.

What Happens When Your Plan is Too Detailed?

Every additional detail you add to your plan removes the need to consider future ideas. As your plan increases in detail, so does the size of the holes in your sieve. The larger the holes in your sieve, the fewer ideas you will capture. This could be a good thing if you have done the work to validate your plan is the right course of action, but this is rarely the case. With a plan that is too detailed, any new idea would have to be well-defined, inescapable, and highly convincing to be caught in the sieve. This means more golden ideas will slip through your sieve unnoticed, causing you to miss valuable opportunities.

What Happens When Your Plan isn’t Detailed Enough?

However, the other end of the spectrum can be just as bad. The fewer details in the plan, the smaller the holes. This will lead to more ideas getting caught in the sieve, even if they aren’t high quality. Because you don’t have a clear idea on how you are getting from the current world to the future vision, you must stop and evaluate everything that looks like a decent opportunity. You inevitably lose the value of your sieve since the goal is to separate the high-quantity, low-quality ideas from the low-quantity, high-quality ideas. The lack of a plan paired with a vision, means considering everything as a potential means to your end.

Find a happy medium that works for your product and what you are trying to accomplish. Define a plan for how you are going to accomplish your vision, just don’t make it so detailed that you can’t investigate golden ideas that come up along the way.

An example is the best way to illustrate this…

Blockbuster, the video rental store of old, had a growing business for years, having 9,000 stores around the world at the peak of their success. We all know the story about their tremendous fall and now non-existence due to a lack of innovation and defeat by Netflix. However, the reason they failed to innovate wasn’t because they had never heard of video-rental-by-mail or online streaming. They failed because their plan was too detailed. Their vision, providing affordable access to video entertainment around the world, is the same vision as Netflix. However, their plan on how to get there, requiring physical storefronts for access to the content they were providing, increased the size of the holes in their sieve. The increased size of these holes allowed the ideas of mail rentals and online streaming to escape. Had Blockbuster removed some of the detail in their plan, in effect shrinking the size of the holes in their sieve, they would have captured these ideas and seen them as another means to accomplish their vision. 

The Sieve Questions

Now that you have your problem statement, vision, and a plan to get there, it is time to make your sieve actionable. 

The questions should accomplish one main thing: help you evaluate an idea and push it through the sieve. These questions enable you to bounce an idea against all facets of your product sieve, either finding a place it gets captured, or letting it fall through and escape. Some organizations may have the same sieve questions, but many of them will be unique. 

Some great sieve questions to start with:

• What would my current users think of this?

• Would this feel out of context for our product?

• Does it align with the vision?

• What part of the problem does this line up to?

• How would my users interact with this in their new life?

• Does it disrupt any part of my plan?

• Would the vision still come true without this?

I have found that the last two questions — and the last one in particular — are the most helpful in making bad ideas escape the sieve. These questions will change over time, and that is okay, they should. If you aren’t changing how you evaluate ideas over time, then you aren’t making progress.

Note: A sieve is different from your product requirements documentation. These documents are typically not created until after you have used the sieve to determine the work is worth building. 

How to use the sieve

Whenever you get a product idea, feature suggestion, or new business opportunity, put in through the sieve. This gives you the best chance to execute on golden ideas instead of only focusing on things that sound the coolest. You should use your sieve the same way each time to ensure you have the same context and perspective for evaluating each idea.

First, re-read, re-watch, or re-listen to your problem, vision, and plan. This keeps you centered on where it is you are headed and how you have planned to get there.

Second, think about the different aspects of the idea by asking questions like: How might it fit into the product? and What are the knowns and unknowns about the idea?. Try to shape it up as much as you can, this will give you a better chance of making sure it is given a fair shake. Shaping shouldn’t take a long time, you only want enough to precisely define the idea. Don’t put something like “build a portal” in your sieve, it won’t stand a chance of getting captured. Shape it up into something more defined, “build a web portal for admin users to access the failed login attempt history of their user population”. One is much more likely to get caught or escape the sieve appropriately. 

Third, ask the sieve questions. There is no hard line on how many questions should be answered positively or negatively for an idea to be caught in the sieve. The answers to your questions should help you make an informed decision with the full context about whether or not the idea fits. If you decide it is captured, now the real work begins, evaluating and building. 

Fourth, captured ideas must always be evaluated for their value. Just like large clumps of dirt can get caught in a sieve with the gold, bad ideas can get caught with the good ones. Identify them, decipher the breakdown that allowed it to get caught, and adjust your sieve accordingly. Just like a fine wine, your sieve should get better and better over time. As you adjust it and get used to using it, you will start to get more and more value out of your sieve. 

Building a sieve for your product can be hard and tedious work on the front-end. It is not something that can be done overnight and will be constantly evolving as you get better at using it. However, if you don’t take the time to build a sieve for your product, your chances of failure and wasted effort sky-rocket. 

Part 1 talked about how important it is to waste hours instead of years. Building a sieve may seem like wasted hours. It won’t be perfect at first and it will be tedious to use. But without the sieve, you will waste years working on features and opportunities that aren’t getting you any closer to your vision.

Everything you and your team works on should be getting your one step closer to your vision. Your product sieve will ensure that is the case. 

If you liked this post, hit the heart button, leave a comment, or subscribe below for more product insights delivered to your inbox every Wednesday.

Subscribe now

Back to Part 1

Thank you to the Compound Writing members who reviewed this post: Richie Bonilla, Sara Campbell, and Patrick Rivera.

If you aren’t a part of Product Solving yet, join the thousands of product managers who read each week by subscribing below.

Subscribe now

“People waste years of their lives not being willing to waste hours of their lives”

- Amos Tversky in “The Undoing Project” by Michael Lewis

Product Managers always have something that needs to be done. User stories need to be created, business requirements need to be written, PowerPoint slides built. All this with countless meetings and stand-ups to attend. It can sometimes feel as if the work doesn’t stop and there is no opportunity to back away from it. Between the actual work that needs to get done and our fast-paced culture telling us that we always need to be busy, there isn’t any room for wasting time. 

Product development is a job that doesn’t have a clearly defined end goal. There is always something else that could be done: an algorithm to optimize, a slight user experience improvement, a new pet feature to implement. When managing more mature products, these types of things make their way into the roadmap simply to keep the product moving forward and to keep the entire team busy.

It shouldn’t be that way.

We should be rigorous and ruthless about validating the value of every single feature or unit of work we add to our products. The opportunity cost of building a feature that isn’t needed is incredibly high. Building something that doesn’t solve a problem for your customer is just motion without results. Over time this can lead to a culture of inefficiency, which makes it harder to compete. 

Understanding how much value a single feature will bring is critical to determining how much effort should be spent on it. This might be counterintuitive to what society (and other product leaders) suggest is the right path to take. However, any amount of time you are spending on a product that isn’t returning measurable value to your customers is likely not worth it.

We Hate Not Being Busy

Inside each of us is a constant tendency to want to do something. Sitting around and not doing anything is painful and our conscious kicks and screams if we try. Social media companies have spent billions of dollars to help you waste time while feeling like you are doing something. Scrolling the infinite streams of low-quality posts on social media feels good in the moment. We despise not doing something.

These infinite streams of content make us feel like we are getting some value from the activity. They make us feel like we are staying close to our friends, keeping up on relationships, managing what events are ongoing, and staying aware of the news. All of these things can be done without social media and (do I dare say) produce even better results.

This lie bleeds over into our work lives as well. We are constantly watching Slack and email. Just waiting for any message that comes through so we can respond as quickly as possible. We tell ourselves that we don’t want to block our colleagues from getting their work done, even though we know it’s just another form of busywork. Commenting on Jira tickets, building another dashboard, and sitting in meetings all fall into the same category. They are all activities that have high motion, low results.

Motion != Results

Therein lies the problem: we often conflate motion and results.

Motion feels good. We feel a sense of accomplishment for getting things done. We are able to check things off our to-do list and show a list of things we accomplished for the week. We feel a sense of pride in how much stuff we are able to get done. We point the finger at others who aren’t getting as much done and use that as evidence that we are better at our job than they are at theirs. Our sense of self-worth commonly comes from the things that we do, the things we accomplish. 

But motion doesn’t always equal results. Motion only equals results when you are doing the right types of motion. 

There is currently a large public discourse (mostly on Twitter) about managing productivity and work volume now that we are living in a fully-remote workforce during the pandemic. One side of the argument is asking how we know that people are working if we can’t see them. What stops them from just slacking off at home watching YouTube instead of getting their work done? This side of the argument even goes as far as to suggest tracking hours spent working using technology that tracks mouse movements (!!). The other side suggests that all of this is unnecessary and that we should only be tracking the output of our teams. If the results are good, then you shouldn’t worry about how long people are working or how much “slacking off” they are doing. 

This dichotomy is a great example of how easy it is to conflate motion and results. Just because you are getting stuff done does not mean you are getting the results to go along with it. A fully completed to-do list at the end of the week means nothing if you were working on the wrong stuff and the motion didn’t lead to any results. I would suggest both sides of this argument are wrong -- the issue isn’t output or hours worked, it is all about results. If you don’t actually get anything done that moves the needle in a meaningful way, you are just busy. 

Stop Working on Valueless Features

This is something product managers do frequently at a larger scale with their products. They are constantly looking for things that will keep the team busy, show a small improvement in the product, and make it look like they have a lot to do. The tendency to want to do something creeps in and overtakes the team. They aren’t satisfied to take a step back, reevaluate the product position and customer usage, and determine if the product is good enough to be left alone. The constant churn on updates to the product that don’t result in any noticeable increase in customer satisfaction or product success metric is motion without results. 

So, what should a product manager do when they find themselves in this situation? 

It’s time to push back against the tendency to want to do something. Be willing to waste hours of your life in an effort to save yourself years.

Michael Lewis doesn’t actually mean to waste time. He explained what he meant by this quote during an interview with Tim Ferris: 

“What he meant was that people don’t back away from their work, and especially the need to always seem busy or be busy stops people from finding things that are really worth doing and sifting the ones that are worth doing from the ones that aren’t worth doing.” - Michael Lewis [emphasis mine]

I think this analogy is incredibly helpful when thinking about our products and what we should and shouldn’t be working on. Sift the things that are worth doing from the things that aren’t worth doing. 

A Product Sieve Will Help You Find the Gold

sift, verb

1. put (a fine, loose, or powdery substance) through a sieve so as to remove lumps or large particles.

2. examine (something) thoroughly so as to isolate that which is most important or useful.

Definitions from Oxford Languages

Sifting a substance to remove the unwanted particulates is laborious, dirty, and time-consuming work. The mental image I get is of a ‘49er at the peak of the gold rush, spending days trying to find small pieces of gold. This is what we should be doing with our products. Search and search again, letting the small, valueless particulates fall to the wayside to ensure we are working on pieces of gold, the stuff that will actually provide results for our product.

One of the critical elements of sifting is the sieve itself. A sieve is the fine-grained screen through which you pass all the material. The stuff that passes through is the waste. But, the stuff that sticks on the sieve is big enough to be valuable gold. You must define what your sieve is before you can get started. 

A product management sieve is usually made up of questions that should be answered. Some examples include:

• What metrics are you trying to impact and what impact are you expecting?

• What problem are you solving for your customer?

• Will your customers love your product more if you do this work?

• Does the required amount of effort align with the value returned?

Creating a sieve is the most important part of this process, and you need to make sure all the stakeholders of the product are aligned. You are creating the tool you will use to determine what should be worked on and what shouldn’t -- their input and buy-in is vital.

Doing this requires trust between everyone involved: your manager, your team, and yourself. You may not have a to-do list at the end of the week to show how much you accomplished, but that is the point. Taking time to talk to customers, read about the landscape of the market you are in, and talking with developers about their ideas is crucial. Take all the time that is required to ensure you are working only on things that are gold, and not things that are just dirt. 

Minimize the Motion, Maximize the Gold

Looping back to the topic we started with: motion doesn’t equal results. Using a product sieve to filter what your team is working on will improve the results of your product and decrease the motion you spend getting those results. You need to be willing to waste hours of time doing things like building a sieve, sifting product features through your sieve, and validating that stuff that comes out is actually important. 

When you stop trying to keep your team busy just for the sake of continuing to deliver features, you will open up the team to work on things that are truly impactful. Sometimes, this means continuing to work on small features that provide incremental value. Sometimes it could mean working on a completely new product that will augment your current one. And rarely, though it can happen, it means abandoning your product to build something that will be better for your customers.

When you find that you are very busy, but unsure if your work is providing the results to go along with it, just take a step back and build the sieve for your product. Sift the work you have planned through it. Make decisions about what work is golden and what work is motion. Minimize the motion, and maximize the gold.

Building a product sieve is a mixture of art and science. Next week we will answer questions about how to build a product sieve:

1. How do I build a product sieve?

2. What are the best formats for the product sieve?

3. Who should be involved in the design of my product sieve?

4. Once the product sieve is created, how can I use it?

5. How do I know if you are using it correctly?

Continue Reading in Part 2

Subscribe now so you are the first to receive next weeks newsletter on Building a Product Sieve.

Subscribe now

And be sure to let me know what you think by leaving a comment or reaching out via Twitter!

Follow Tyler on Twitter

Thank you to the Compound Writing members who reviewed this post: Richie Bonilla, Sara Campbell, and Patrick Rivera.

Subscribe now

Open Google Docs. Start writing. Break. Continue where you left off. Take a few days to let the content settle. Edit. Turn on link sharing. Send the link to the team.

If you're a product manager and this is the routine you follow when writing, you aren't getting the full value. Writing in product management is something that should be done in public, with feedback provided early and often. Your writing should have the etchings of others all over it.

Building a product is a team exercise. It is rarely something that should be done alone. Even from the very start.

Subscribe now

Why write in public?

Writing is something a product owner is very familiar with. Requirement documents, acceptance criteria, ticket descriptions, product demo slides, product vision statements, product strategy, data analytics reports... the list goes on and on. However, most product managers are only familiar with writing on their own. It feels comfortable, minimizes the risk, and is much less scary than making everything open from the first word. Presenting your ideas to the world (read: your team) in a formal document after you have done most of the work is too late.

Write in public, (almost) always.

Sometimes it's appropriate to share it with a subset of your audience. Most of the time it's appropriate to share with all of your audience. Either way, sharing before you get started is the name of the game.

Writing in public does a few things, some of which benefit others, all of which benefit you.

Note: “public” in this article simply means the ultimate audience for your work. It does not mean the greater public.

Generate Better Ideas

Getting an email about a comment on your newly shared Google document is exciting! Your mind races wondering how the document was received. Until you realize it's a question you should have thought of. One that pokes a hole in your core argument and will require more rewriting to flesh out. “Why didn't I think of that earlier?”, you ask yourself.

Getting comments on your work before it is finished means avoiding the ultimate facepalm moment after it's finished. Others might write a different ending to the story you wouldn’t have thought of otherwise. Once you set a specific solution or direction in front of your team, you are planting that as the default solution in their mind. This means that some members of your team won’t even chime in and offer a different solution at all (especially if they are quieter members of the group). Silence isn't good. There should always be some dialogue around the ideas you write about.

Giving the team the ability to see the progress on the story you are telling leaves things open-ended. Before you even get to the end, your team is writing the end of the story in their mind. The human brain doesn't like unresolved problems. That means your team will use all of their mental models and put them to work at solving this novel problem. Your novel problem. You might be surprised what some members of the team suggest: New roadblocks you were blind to; Potential solutions that didn't even cross your mind. Your work will be better automatically by sharing early with the team.

Let People Read Your Mind

You are constantly having to convince others why your ideas are the ones to put resources on and spend money toward. Being influential and inspirational is a primary part of the job. To make this work, you have to be ready to rock and you must be convincing.

This isn’t the case with a team of peers, however. Your peers are wanting to know how you got to the end result and what else you considered along the way. Writing in public enables your team to literally read your mind as you flesh out ideas. They can see which parts you struggled with, which ideas flowed easily, and how you resolved the toughest problems. Don’t let the burden of perfection stop you from giving your team the insights they are asking for.

Spend Less Time

Writing pieces of work that are polished and ready for executive review takes time, sometimes more time than is available. Most product folks (myself included) like to have things polished up and ready to roll before we unveil it. But, writing in public and letting others think about hard problems with you enables you to get much more done. Sometimes you need to stop the madness of making sure every single T is crossed and I is dotted before it needs to be. The developers on our teams call this premature optimization. Don’t fall into the same trap and wait to unveil your work until it is too late. Just like your product, releasing early and often leads to better results.

As a product leader, I encourage my team to bring me their half baked ideas and their hardest problems as early as possible. Breaking down the wall of perfection helps make this possible.

Build Team Ownership

When the team sees the product manager building ideas from scratch and gets to participate in that process, they own the ideas more. Product leaders are constantly trying to find ways to increase the sense of ownership amongst the teams. Writing in public gets you there. It shows more of your thought process, the challenges you are trying to solve, where you started, where you ended, and invites your team to join in for the journey. Who knows, you might even incorporate one of their ideas along the way! Talk about increasing the sense of ownership.

Answer Questions Once

Having your team comment on your writing while it is in progress is a hidden superpower. Inevitably, every PO has written a long doc or designed a large system feature only to be met with a multitude of questions out of the gate that are easier to answer in a live conversation. When you write in public, you get the benefit of those questions getting asked early on and the responses are recorded for all to see. No more answering the same question multiple times.

The old saying from our grade school teachers rings true, “If you have a question, someone else in the room probably has the same question”. Using a tool like Google docs or Confluence allows you to track the history of your document automatically and have a record of all comments and conversations on that document. Everyone on the team gets to stay in the loop and nobody has more insights than anyone else.

Enable your writing to answer the questions in the room before you even show up. This makes your end product clearer, and more effective.

Thinking Out Loud

One of the things that I have found to be the hardest in leading a product team is to teach decision-making skills. Everyone uses a different set of models and understandings of reality which can lead to very different decisions getting made. (In fact, that is one of the reasons I write this newsletter… to help myself think through the best ways to make effective product decisions.)

I would argue that, perhaps, the most important reason to write in public is to give your teammates the ability to watch you reason about and wrestle with a problem. When you open up your writing process for others to see, you are “thinking out loud”. By doing this you can teach your decision-making process to the other members on the team. This will not only increase the alignment on your team, but may also help your peers improve their decision making while you let them help improve yours.

It Breaks Down the Barrier

Publishing something you have written is intimidating and nerve-wracking. All sorts of questions circle in your mind: “What will others think of it?”, “Am I any good at writing?”, “What if I have missed something and get embarrassed?”. All of these are feelings that even the most prolific writers feel. The difference is that they pushed through it and kept writing anyway.

Informal writing is one of the best things you can do to cultivate a culture of writing in your company. You can help your team feel like they don’t always need to have things completely put together before they begin sharing and writing. The ideas they have will flow out onto the paper more easily and you will get better insights from your team as a result. Once this happens, it is just a matter of time before everyone is writing effectively. This one practice will increase the communication factor of your team many-fold and is worth the effort it takes to get there.

What About My Ego?

Writing is a skill that is significantly underdeveloped in most adults. We are all over-conscience of our writing, whether it is good or not.

Here is a tip: If you are writing at all, you are already ahead of most people.

Don’t worry about letting people see your first draft. If anything, it might inspire them to start writing as well, helping develop that culture of writing at your organization. When others see a rough first draft turn into a product design that is lauded throughout the organization, they see how hard you are working (bonus points) but they are also inspired to action themselves. And that is part of your job as a PO... inspire the people on your team to action.

Just Get Started

Open up a Google doc, send it to your team and let them know you will be working on your next product document there. It is that easy. Some of them won’t look at first, so you will get a bit of a head start anyway. But eventually, they will see all the hard work you put in and be inspired to action.

Subscribe to Product Solving to learn how to be a better product manager each week.

Subscribe now

If you want to talk to me about this article or want more content like this throughout the week, follow me on twitter:

Follow Tyler on Twitter

Subscribe now

Good product managers understand the map. Great product managers understand the territory. The best product managers build and understand maps so others can understand the territory.

Good product managers know the market, the product, the product line and the competition extremely well and operate from a strong basis of knowledge and confidence. - Ben Horowitz

Alfred Korzybski, a mathematician, presented a paper on mathematical semantics to the American Mathematical Society in 1931. In this paper, he introduced the phrase the map is not the territory. He later explained this as meaning words are not the things they represent. By their very nature, words are an abstraction (or a map) of the things they represent. And by definition, a map is a lower fidelity version of the territory it represents.

Note: This article uses the word “map” in a more general sense. I am not referring to a map of a physical landscape (although this could be the case for some products) but rather a map of human understanding.

In building products, we utilize maps all the time without realizing it. A common map is our view and understanding of our product market. Industries are incredibly complex and have international value chains. In today’s world, you can be the top expert in a domain and still use maps to understand how it works. These maps are simply abstractions, or lower-fidelity explanations, of how the real system works.

A common map product managers lean on is their understanding of the technology used to build their products. Product managers are not technical in many cases, but having an understanding of how the technology their team uses enables better communication and product design. This means product managers must understand the concepts behind their team’s technology stack without any formal training in that domain. This requires the product manager to build a map of how that technology works and fits together.

There are many other types of maps we use every day. Anything we use as a shortcut to understanding something more complex than we can hold in mental RAM would count as a map.

While these maps are extremely useful for us, we have to be sure to consider a few important things while we use them:

1. Maps can be incorrect without our knowledge (especially if we don’t understand the territory)

2. Maps don’t show the entire landscape (otherwise it would no longer be a map)

3. Maps are only valuable to a point for amateurs (only experts can utilize them to their full potential)

4. Maps are made by someone with an agenda (that could be ourselves or others)

All of these have great consequences for how we utilize maps in building products. Maps can be tremendously helpful in building a great product. Especially if you don’t need to understand the full terrain. The key to using a map effectively is knowing how and when to work around these limitations.

Maps Can Be Incorrect Without Our Knowledge

Remember that all models are wrong; the practical question is how wrong do they have to be to not be useful. - George Box

All maps are going to be wrong in some places. If they weren’t, they would cease to be a map and would be the territory they represent. This means we should always be on the lookout for places where our map is wrong, and be proactive about making changes to ensure it doesn’t hurt the way we build our products.

The biggest place this can bite you is mistakes in your map of how your target market operates. Having mistakes in your understanding of a process, a legal requirement, or even just how much time your users have to use your product can be detrimental to what you are building. Without constantly revisiting these maps you will, at best, build something that is not needed and, at worst, build something that causes harm to your customers or their customers.

Unfortunately, the feeling of being right and being wrong is exactly the same until you notice you are wrong. This is the same with your map. You have no reason to assume it is wrong until someone tells you otherwise.

If your map is wrong, big iterations will be costly. Work in short cycles and search for continuous customer feedback to revise your map. These small adjustments will ensure you are headed in the right direction and are building something your customers need and will use.

Maps Don’t Show the Entire Landscape

There are parts of the map which cannot (and should not) be reduced to a lower fidelity version. Your job as a product person is to know the landscape enough to make decisions about which parts of your landscape should not be reduced.

Imagine you are taking a bike ride and you are headed up the side of a mountain. The map says the road travels straight up the mountain, only a 2-mile drive. You assume this means it has a specific grade (incline) and ensure it fits within your training regimen. But, when you actually get to the base of the mountain, it is a windy road that totals 5 miles and has a much lower grade throughout. This may not be a big deal if you are riding for enjoyment (and may be referred to as the shorter, harder ride). However, if you were counting on that hard and fast incline, you are out of luck.

This is the same in building products. Removing the fidelity from the map can be very helpful in simplifying the landscape, getting people to understand the big picture, and helping plan courses without worrying about small details. But, if you accidentally reduce the fidelity of your map in the wrong places, the consequences can be great.

Brushing over what appears to be a small detail to you, could be a completely unusable product to your customers. It could also mean a completely misunderstood landscape for your team members.

It is your job to understand the landscape of everything around you enough to know when it is appropriate to reduce the fidelity, and when it is not.

Maps Are Only Valuable To a Point For Amateurs

“A model might show you some risks, but not the risks of using it. Moreover, models are built on a finite set of parameters, while reality affords us infinite sources of risks.” - Nassam Taleb

If you are an amateur in part of the domain in which you work, you are not going to work as effectively as you could. This means that most of your job as a product person should be learning and understanding the problem, and how the industry surrounding the problem works. Becoming an expert in your domain helps you understand not only what risks the model shows, but what the risks are in using that specific model.

In chemistry, many different maps are used to understand the territory. The way we visualize molecules is a great example. Most visualizations of a water molecule look something like this:

A novice might assume this is what the actual molecule looks like and wonder why water is blue instead of red. However, the expert would know this model is only useful in understanding the relative size, distance, and angles between the individual atoms. They would combine this with many other maps to get a better understanding of what a water molecule looks like:

Find trusted experts, they can use your map more effectively and help you build your map (and potentially combine it with other maps) to be used by others most effectively. The most important thing in using expert resources is to internalize what they are telling you. As a product person, you should be the expert on your team about the customer, the industry, how the product works, and what problem you are solving. Without being this expert, your maps will be meaningless and won’t be valuable to anyone on the team.

Maps Are Made by Someone With an Agenda

When you build a map of the problem space you are working in, there are always assumptions that will be made. These assumptions are what lead to problems like the ones listed above. In order to avoid these assumptions, you need to know who is working on the map and what their motivation is.

Whenever we are building a map of a territory, there is some motivation to do so. We are likely trying to understand something complex in a way that is useful to frame a problem. We may be trying to find a place to use a solution within that domain. We may be trying to convince ourselves that something will work within the landscape when data may be saying otherwise.

Knowing the motivations of the map-maker will ensure you can look objectively at the map and see where mistakes or assumptions were made. You can see why parts of it were lower-fidelity and ask why. You can understand how the problem was mutated in order to fit a model that is easier to reason with and build products within. Knowing the landscape well enough to look for these inconsistencies can help you understand what it is you need to focus on as a product person when you are building.

Maps are an incredibly helpful thing to use when building products and reasoning about complex domains. Sometimes these maps are simply a diagram of a system. They may be a mental model of the way an industry works. It could be the product vision and strategy documents you create to keep your team marching to the same drum. All of these are maps of a territory, made to take something infinitely complex and distill it down to something more useful.

But remember, the map is not the territory. The reality may be something simpler, it may be more complex, it may be completely different than what is represented in the map. Build maps that are useful for you and your team. Look objectively at the maps built by others. And be willing to constantly revise your maps to adapt to new information.

If you enjoyed this essay and are interested in how to build better products, follow me on Twitter!

Follow Tyler on Twitter

Subscribe now

“You focus on the what, and stop telling me how to do it.” - Every Engineering Leader Ever

Many people have heard that the product team focuses on the what and the engineering team focuses on the how. This is a great mental model to use when determining whose responsibilities are whose, but figuring out the what can be challenging. If you aren’t deciding how a product is built as a product manager, then what are you doing?

The key here is to align your understanding of what and how to something more tangible, problem space and solution space.

Dan Olsen introduces the idea of problem space and solution space in his book, The Lean Product Playbook. This way of addressing how to build a product, or how to build the next iteration of your product, is extremely helpful to make sure you are building something that matters. It is your job as a product manager to live in the problem space.

What is the problem space and solution space?

Problem Space

Three main concepts make up the problem space: target customers, their underserved needs, and your value proposition. Problem space does not have any specific solutions or designs to serve those customer problems.

Target Customers

Identifying your target customer is the foundation of your success as you build a product. Build a persona to help your team understand who they are building the product for, and to help you ensure you are solving for the right customers' needs.

Underserved Needs

Needs is synonymous with wants or value. This can be challenging for your customers to communicate with you. Most of the time, customers are fairly bad at discussing the problem space. Instead, they do a better job of talking about what they like or dislike about particular solutions (solution space). Use this to your advantage. When they tell you what they like about a solution, bring yourself back into the problem space by asking yourself, Why would this create value for the customer?

Value Proposition

The generation of your value proposition is dependent on a good list of underserved needs for your target customer. You are not creating anything new in the value proposition phase. You are making decisions about which needs you will address with your product and which needs you will ignore or push to a future version of the product. Every time you enter this stage, you should be thinking in terms of the MVP.

Aside on the term MVP:

Your MVP, or Minimum Viable Product, is not a complete version of your envisioned product with each feature half-implemented. MVP does not equal crappy. A true MVP involves ruthless and rigorous decision making about what the highest value features are while generating your value proposition. Your MVP should have very few features and it should do those things extremely well.

MVP != Lots of half-baked features

MVP == Few fully-baked features

Solution Space

Solution space includes your product feature set and the UX. The solution space includes any type of product, product design, wireframes, prototypes, mock-ups, etc. Anything that describes the product the customer will use lives in solution space. In the solution space, you have decided upon a specific implementation of the product to solve the customer needs identified in your problem space.

Feature Set

This is the list of things your product will do to provide the value proposition outlined in the problem space. The feature set selected is defining your solution and how it will work, getting into the how part of the implementation cycle.

UX

As the last layer in the Product-Market fit pyramid, the UX, or user experience, is how your customers experience all the layers below it, namely your feature set. All the work done up to this point will be encapsulated in the UX. As this is the way your customers benefit from your product, the UX should be clean, easy to use, and make the value you are providing abundantly obvious.

Your Job Is to Live in the Problem Space

“Fall in love with the problem, not the solution, and the rest will follow” - Uri Levine

As a product manager, your job is to live in the problem space. You should spend nearly all of your time focusing on your target customer, what needs they have, and what value you are going to provide to them. Nobody else in your organization is set up to spend time in the problem space like you are.

Sales is focused on selling the product: solution space.

Marketing is focused on marketing the product: solution space.

Operations is focused on supporting the product: solution space.

Engineering is focused on building the product: solution space.

Design is focused on designing the product: solution space.

Nobody else in your organization is worried about the problem space. That is why you are there. If you aren’t spending time in the problem space, you are very likely building something nobody is going to need.

Ask yourself: Why would this create value for the customer?

The fastest way to get yourself back into problem space and out of solution space is to ask yourself: Why would this create value for the customer?

This single question forces you to think in terms of who your customer is and what problem you are solving for them. Then you can use these pieces to information to make sure the solution being suggested aligns with your value proposition. If not, toss it out or push it to a future version of the product. You have to be ruthless about ensuring you are only working on features that align with your current value proposition.

NOTE: Your value proposition is likely to expand and change as your organization grows and matures. The value proposition will change as a result of customer feedback, expanding the product scope, and entering new target markets.

4 Parting Thoughts

1. Problem Space == What; Solution Space == How

2. As a product manager, focus on your customer, their needs, and your value proposition, and the rest of the work will follow.

3. Create artifacts along the way for your team to use, don’t let everything live in your head.

4. Keep finding opportunities to get yourself back into problem space and think about the customer, that is the reason why you are building a product in the first place.

My twitter followers got a preview of this article nearly a week before it was posted!

If you like this post and want to enjoy content like this more frequently, follow me on twitter.

Follow Me on Twitter

Subscribe now

"If only I had the time to work on ______________."

This is something I say to myself frequently and I consistently hear from business leaders and colleagues. Finding the time to work on the highest leverage tasks can seem impossible. This effect is compounded by the fact that product people tend to be detail-oriented by nature. This isn’t a bad thing, you want everything about your product to be perfect. But perfectionist tendencies can get in the way of enabling your team to flourish.

When you find yourself wanting to double-check other’s work, make sure things got done correctly, or simply don’t have the time to teach others how to do the job, you are working on things that provide less value than you can bring to the table.

So how do you start to work on high leverage tasks? Start by getting out of the business of doing your colleagues or subordinates job. Once you have done that, find the highest leverage tasks, prioritize them, and turn the other tasks into an exercise of finding leverage.

How do you do this?

Subscribe now

Finding the Highest Leverage Tasks

“Forget rich versus poor, white-collar versus blue-collar, it’s now leveraged vs. unleveraged.” - Naval Ravikant

Identifying the leverage of a task can be challenging. There are two ways I have found to best identify high leverage tasks.

1. Ask the question: Will this work provide 80% of the value for 20% of the work?

Following the Pareto Principle in your thinking will enable you to find tasks that are worth your time and will provide significant value to your colleagues. These can be:

• shaping up the design and mockups for the executive pitch

• providing a well-defined writeup for your team to execute on a project

• making a high-profile decision about which direction the team should go

• building documentation that will create self-service opportunities for your team

These are the kinds of things that you can do to jump-start the team and get them a successful start along their route.

As a product manager, you have a unique perspective on how to get things moving in the right direction, and if you can get things 80% of the way down the right path, your team is set up for success.

2. Build content that casts a vision and enables the team to stay on track.

“Good product managers create leveragable collateral, FAQs, presentations, white papers. Bad product managers complain that they spend all day answering questions for the sales force and are swamped. Good product managers anticipate the serious product flaws and build real solutions. Bad product managers put out fires all day. Good product managers take written positions on important issues (competitive silver bullets, tough architectural choices, tough product decisions, markets to attack or yield). Bad product managers voice their opinion verbally and lament that the “powers that be” won’t let it happen. Once bad product managers fail, they point out that they predicted they would fail.” - Ben Horowitz

Your team should know exactly where they are headed and what it looks like when they get there. If your team doesn’t have this type of vision, it is not surprising you are spending a lot of time on low-leverage tasks to keep the team on the right path. Enabling your team to be self-sufficient by providing them with a well-defined vision will keep them focused and enable them to exercise their creative muscles while keeping the ship steered in the right direction.

The second important idea when casting a vision is to ensure you put some guardrails on the path and let your team know what success does not look like. This includes things like:

• What would happen if we failed in our vision?

• How do we know we are starting to head off course?

• What types of activities will guarantee us failure?

• What things have you learned along the way and know to avoid?

Using a mental model called inversion enables you to come up with these ideas to share with your team. A combination of “where are we headed” and “what will make us fail” narrows the direction for your team and enables them to thrive without your constant support.

Here is the key: you need to write these things in a way that is clear, reference-able, and understandable to all members of your team. Having these written down allows your team to constantly come back and reference them when they need to. Think of this as putting up a highway sign and guardrails on a bridge. You want to let people know exactly where they are headed (highway sign) but you also don’t want them to accidentally drive off the side of the bridge (guardrails).

But remember, you don’t take down the guardrails after you’ve shown them to the drivers once. You leave them up as a constant reminder about where you are headed. Your product vision should do exactly this for your team.

Make Your Expectations Abundantly Clear

Making sure you set clear expectations with your team is critical to give yourself the space to act on activities of leverage. Not letting your team know what types of documentation you require as a status update means you will need to schedule a meeting while they play a game of “guess what the teacher is thinking” (don’t make your people play this game with you... tell them what you want). Make your expectations clear, let them write down what you need to know and send it to you. This mostly benefits you in the long run. You can read it whenever it is most convenient for you, and they will have time to create well-formulated and understandable thoughts. Over time, you and your team will have documentation about what is going on that you can reference at a later time.

Create a culture of writing in your team. It starts with you. Cancel meetings and provide an update in writing instead. Ask your team to write down things they want to talk about in a shared doc and use that to communicate throughout the week. There is no need to meet about something where one person is providing most of the context.

Ask your team to create a dashboard with all the detail you need to get a full view of the project status. Then you must review the dashboard so you stay up to date. Don’t waste your team’s time because you are too lazy to read a dashboard and ask specific questions to people on your team. Let them do their job and give them the time to do it well.

Do the Things You Always Wanted to Do

Now that you have your team working on the tasks you need them working on, they are headed in the right direction, and they know how to avoid heading down the wrong path, you suddenly have time to work on the highest leverage tasks. You can do market research, creating a report that shows where the industry is headed in the next 5-10 years which helps you pitch product changes to your executive stakeholders. You can spend time talking to customers, identifying which parts of the product are the most used and least supported. You can train your team on the value of the product they are building so they take more ownership over the activities they are responsible for.

Give your team the tools they need to succeed, provide clear expectations, and give them the space to execute. You will be pleasantly surprised by what your team will do.

If you liked this post and want to get notified of new posts, sign up below.

Subscribe now

Join hundreds of other entrepreneurs, product managers, and developers in leveling up your product building skills. Subscribe now so you don’t miss out on the next post!

Subscribe now

People are lazy.

They don’t want to think hard, they don’t want to make decisions, and they don’t want to be accountable... at least on the surface. I have found this to be the case with so many people that I have worked with throughout my career. Let’s see if this sounds familiar...

You head into a conference room to attend a meeting about a new project. Your boss, their boss, the project team, the product team, and lead developers are all in attendance. Your bosses, boss kicks off the meeting by describing the project at a high level, set up the vision, and hands it over to the lead project manager. The lead PM then goes through the project plan but doesn’t get very far before someone asks a detailed question about part of the implementation. It isn’t even a big part of the project, but they want to know. You look around... different team members chime in to give their two cents. The project manager doesn’t agree with the product owner and before you know it, the project kickoff is derailed into chaos. Most of the biggest questions haven’t been answered, and you are tasked with figuring things out on your own.

This is the Bike-Shed Effect in action — choosing to spend time and energy on the most trivial parts of a project.

The Bike-Shed effect (sometimes known as the law of triviality) is an argument first made by C. Northcote Parkinson in 1957 that members of a team will give disproportionate attention and time to trivial issues, such as what color to paint the bike shed (hence the name). Parkinson argued that most of the time spent on a project is spend on the trivial and easy-to-grasp issues.

"The time spent on any item of the agenda will be in inverse proportion to the sum [of money] involved." - C. Northcote Parkinson

Most complex projects are challenging to understand and people on the team will not understand all the parts of the project. Because of this, they will talk about the parts they do understand, typically the more trivial issues.

Trivial Ideas are Easy

Thinking and debating about trivial ideas not only helps keep one’s nose clean, but also takes less mental energy. This is why we do it so frequently. It is something we may not realize we are doing at the time.

Just like electricity takes the shortest route to the ground, our mind takes the easiest route toward our goals. Most of the time, our goals are contributing value and speaking up. We want to contribute something to the project without making an incorrect choice. This means that we are very likely to pick something to talk about that is easy, that we know a lot about, or that we don’t have to worry about making a big mistake on.

Parkinson would explain this by suggesting that easy or trivial ideas are anything a single person can understand and conceptually maintain visualization of in their mind’s eye.

If Everybody Does The Easy Work, You Will Fail

The problem isn’t necessarily that we always want to start with the easiest tasks. Sometimes this can be a good way to get ramped into a period of work. The issue is when everybody takes the easy way, and wants to make their mark. This drives the team to argue about parts of the project that few will care about in the end.

Wasting time on the easiest items means the hard questions never get answered. The team will suffer from a lack of coordination and direction on how to get the hard and complex items done. This will likely ultimately lead to a single person carrying the load or the project failing.

Force People to Do the Hard Work

Make people write.

“When you have to write your ideas out in complete sentences, complete paragraphs it forces a deeper clarity.” - Jeff Bezos

Give them a part of the problem, make them write down their solution, share it in public before the meeting, and discuss them. Fleshing out ideas in writing makes everyone think for themselves. Thinking for yourself (especially in private as is the case with writing) is the easiest way to force yourself to resolve the hardest problems you are facing.

On my product team, we implement a shared weekly meeting agenda. We have a shared Confluence document to which we add items needing discussion. Each person can comment and maintain a dialogue on items other team members have added. Here is the catch: The additions you make to the doc must be complete and fully thought out. Everyone on the team should be able to understand them without additional context and without you needing to explain it live. This forces everyone to think about how they want to articulate their items. This ensures everyone stays on the same page, even if we don’t have time to get through our entire agenda.

Another way to force thinking about a problem is to require the meeting leader generate a 6-page document with the proposed product implementation and solutions. This methodology has been implemented at Amazon for years. Each person gets the document ahead of time, they come to the meeting prepared, and then they spend the first part of the meeting rereading the document. This rigor ensures any interrupting questions don’t get asked because they are answered later in the document. 6 pages of writing also requires the author has spent quality time ensuring their ideas are well thought out, clear, and concise.

People Want Hard Work, So Enable Them

The team around you likely has a lot of really good ideas. They know more than they can communicate in a meeting for which they are unprepared.

I started this article saying:

People are lazy. They don’t want to think hard, they don’t want to make decisions, and they don’t want to be accountable... at least on the surface.

I will end the article with this...when people are thrust into a situation for which they are unprepared and feel insecure, they tend to come across in a negative light. If you can set up an environment in which they feel prepared and equipped, the story changes.

People want to feel the satisfaction of working hard. They want to contribute effective and noticeable decisions to the team. They want to be held accountable when they feel confident in their work.

Give your team the ability to shine. Force them to come prepared and ready. Your team will thank you for it and your customers will notice you spending time working out the hard things and not just polishing the easy things.

If you liked this post and want to get notified of new posts, sign up below.

Subscribe now

Subscribe now

What would it look like if you could ensure your team was working on the right stuff at all times?

They would be able to translate between where you are now with where you are going. They would be able to make good decisions about the architecture of the product to ensure future success. They might even highlight flaws with the direction of the product and work with you on ensuring it is correct.

Unfortunately, this isn’t a reality for most of us. Between urgent requests from stakeholders, customer bugs, and an overly-optimistic roadmap, most of us are barely keeping our heads above water, let alone spend enough time with our team to ensure they are never wasting any effort.

Using inversion will help you work on the high impact features you know your customers will love and ensure your team knows where you are headed.

We should operate with certainty that we are always working on the most important things. So that begs the question, which customer requests should we work on? Which requests should we avoid? Most of us have a set of criteria to evaluate a new feature request, but it doesn’t have to be complex if we start at the end and work backward.

What is Inversion?

Starting at the end and working backward is called inversion. Inversion is a powerful mental model popularized by the vice-chairman of Berkshire Hathaway, Charlie Munger, but it has its roots in mathematics. The main principle of inversion is to turn your problem around, start at the end, and work from there. This will ensure you see your problem in a new light and end up at the destination you set out for.

By combining forward and backward thinking we can see a better picture of reality and solve problems that seemed unsolvable. Take the following problem: what is the square root of two? Today, we know the square root of two is an irrational number, but in 200BC the Greek mathematician, Hippasus, was trying to figure that out. Other mathematicians at the time were trying to solve the problem by continually dividing larger numbers into each other. Instead, Hippasus turned it around and thought about what the implications of a solution to the square root of two would be. By thinking about what has to be true about mathematics and the world if we knew the square root of two, he discovered the first irrational number.

This type of thinking, achievement thinking, forces us to think about what the world would look like if we succeed in our pursuits. But there is another side of the inversion coin that can be even more valuable, failure thinking.

Investing in the stock market is typically viewed in one direction, how do I maximize my gains? Failure thinking is going to turn that goal on its head and instead investigate how to minimize losses. This type of thinking resulted in one of the greatest ideas in investment history, index funds. Finding ways that will guarantee your failure enables you to steer clear of paths that you may otherwise be blind to.

Applying these two types of inversion, achievement and failure thinking, to building products may not always be clear… let’s dive in.

Achievement Thinking

“All I want to know is where I’m going to die, so I’ll never go there.” - Charlie Munger

Find assumptions about the problem you are solving by identifying what else must be true if you succeed. By working backward and breaking down those assumptions, you can find roadblocks you may not have anticipated.

Start by defining what the best-case scenario is. It could be what a feature looks like or what the optimal outcome to a problem would be. In the new world you have created, answer two questions:

1. What are my users now doing?

2. What are my users no longer doing?

The answer to these two questions should inform how you market, build, and train users on your product.

In the B2B space, the answers to these two questions can mean less manual labor as a result of implementing your product. One of the greatest problems you will have to ensure you answer when implementing your product is “what will my current employees do if they no longer do X.” Make sure your product explains positively how your users' future world will look. Change the world around them so they can utilize your product without hesitation.

Achievement thinking will help you find new steps you might have missed or gaps that need to be addressed. While this technique is easy to implement, it enables you to cast a vision of where the team is headed, and help people think about how you are going to get there in a different way.

Even though this is the most common way to implement inversion, I would argue failure thinking is an even better way to implement inversion in your product team.

Failure Thinking

To apply inversion to your everyday work as a product person, you must be able to use it when deciding a grand vision of the product, and also when deciding on the smaller details of running a product team every day. Do this by listing everything that will make your product fail. Maybe it is adding too many features before others are finished. It could be ignoring technical debt and not building your product for scale. Sometimes it is as simple as not communicating clear expectations to your team.

Compiling a list of things that will ensure your product fails gives you a filter through which to pass every request that comes your way. It doesn’t have to be a long list, about 5-10 criteria that will guarantee failure.

Let’s think of an example:

A stakeholder comes to you asking for a new feature to be implemented immediately for a customer. You ask for some more details and compare that to your list of failure criteria. You remember that one of the items on your list is that leaving any feature halfway done will ensure your product fails. You look at your roadmap and realize you are halfway through implementing another big feature. Because executing on this feature immediately is going to leave another half-baked, you have the confidence to let them know it can’t be worked on right now.

One thing I have found to be successful in implementing this model is getting buy-in from your stakeholders. Let them know you have created a “how we fail” list and iterate until everyone agrees. Getting this buy-in enables you to direct them to that list whenever you use it to say no to a stakeholder request.

Providing your team with a “how we fail” list also gives you the confidence that your team can act autonomously without steering off in the wrong direction. Failure thinking provides guardrails to ensure your product stays on the path to success.

“It is remarkable how much long-term advantage people like us have gotten by trying to be consistently not stupid, instead of trying to be very intelligent.” - Charlie Munger

Achievement thinking provides your team with insight into what the world looks like when you have reached your destination. Calling out any assumptions explicitly to ensure you address them while you are on your way.

Failure thinking gives your team guardrails to ensure they aren’t working on the wrong things and gives you confidence they are on the straight and narrow.

Using both achievement and failure thinking together gives you a framework to think about building your product from an inverted point of view. Combining this with your forward-thinking roadmap will make you unstoppable in ensuring your product is a success.

The biggest question we are always asking ourselves as product people, “Am I working on the right things? The biggest value and highest impact things?”. If you have a set of criteria you have developed using inversion, you don’t have to worry about ensuring you are working on the right things. As long as you are not working on the wrong things, you are moving in the right direction.

If you liked this post and want to get notified of new posts, sign up below.

Subscribe now

To build a great product people want, you have to think. Hard. Really, really hard. And you have to think a lot. Most of your energy is spent thinking.

So let’s do something to make ourselves faster, better, and more innovative thinkers!

Subscribe now

Icons made by Flat Icons from www.flaticon.com

“I believe in the discipline of mastering the best that other people have ever figured out. I don’t believe in just sitting down and trying to dream it all up yourself. Nobody’s that smart…” - Charlie Munger, vice chairman of Berkshire Hathaway

Nobody’s that smart... we need to stand on the shoulders of giants, use what they figured out, and think from there. But standing on the shoulders of giants in our domain isn’t enough. To be a great problem solver and a great thinker, Munger suggests we need to know the big ideas from all major domains.

“You must know the big ideas in the big disciplines and use them routinely – all of them, not just a few. Most people are trained in one model – economics, for example – and try to solve all problems in one way. You know the old saying: To the man with a hammer, the world looks like a nail. This is a dumb way of handling problems.” - Charlie Munger [emphasis mine]

That is an intimidating task. So how do we learn “the best that other people have ever figured out” in “the big disciplines”? And once we know it, how do we use it? Enter mental models.

Using a latticework of mental models from all the great disciplines gives us the ability to start with the best thinking and see every problem from a different perspective.

This is the key to building great products. See what others don’t. Ask what others won’t. So you build what others can’t.

This is what Product Solving is all about. Using mental models in your day-to-day routines.

In this newsletter, you will explore a different mental model every Wednesday, right from your email inbox. You will find out how to apply each model, when it makes sense to use it, and why it will change the way you think.

Subscribe to get be the first to know about each new posting and get it delivered directly to your inbox.

Subscribe now

This newsletter will focus on how different mental models apply to building products, but having a latticework of mental models extends beyond work. I have found that a rich latticework of mental models extends into every area of life, making me more productive, more insightful, more engaged, and more knowledgeable.

I am looking forward to revealing how I have used mental models to build products and come up with ways to break outside the norm and be truly innovative.

Share this with someone who you think would enjoy it so they don’t miss the first week!

Share Product Solving