Chalk X

People often confuse many things for value. Here are just some of them: excitement, urgency, trends, hype, complexity, interest, short-term cost savings, ease, loudness, and quantity. Let’s try and categorize these.

Fooled by who was saying it

Many of these things are confused for value because of who says it. A well-known acronym in product management circles is HiPPO, which stands for the Highest Paid Person’s Opinion. A manager is a stakeholder, not a customer; just because they have an opinion doesn’t mean it holds value.  I mentioned loudness in my list because sometimes the loudest person in a room, regardless of position, may get their way even though what they say doesn’t have value. Unfortunately, more insidious versions of this are sexism, racism, or some other preconceived notion that limits us from being able to evaluate someone’s words unencumbered by who they are. 

Fooled by feelings 

This sort of value is because an emotion is associated with our decisions. They can be preconceived notions or how we’re reacting to change. An environmental change, newness of a concept, or excitement like we’ve seen with AI, blockchain, big data, or any of the other trends in the past. When the excitement turns to a trend, a lot of times, the new feeling is the feeling of being left out. Are we doing something because somebody else is doing it, and we will be seen as behind, or not as cutting-edge, not as good? Our feeling of personal worth and emotion gets commingled with actual monetary value.

Fooled by numbers

To rule emotion out, sometimes, we try to stick with numbers as we believe they are unbiased. Delivery X amount by Y date. Some companies, luckily none I’ve ever worked at, have decided that the quantity of code that is written is vital to measure. This metric, like many easy-to-measure measurements are vanity metrics that can make us feel good about how much we’re doing. Anyone familiar with Goldratt’s work or the work that stems from it would know that overproduction, just like overproduction of inventory, is a form of waste and not value. Any code we write that isn’t used to generate value must be maintained, edited, and sometimes sifted through if there’s a problem. Ultimately, this, too, is a waste. Another vanity metric in agile development circles is the team’s velocity and how many story points or tasks a team could deliver. Because it’s easy to measure, it has more value if we get more of it. This easy-to-measure concept can confuse us as we believe it’s the data I have, and data is quantitative and therefore necessary. But all data is qualitative. 

For example, I could count the number of chairs in the office. This could be a metric, but the metric doesn’t tell us much because we can count it. You may have a storeroom in your building for extra office chairs. Simply picking what you want to measure is qualitative.

Many of the things I’m describing have been well-documented as cognitive biases. Simply because we’re human, we have a blind spot toward the truth. When dealing with product management prioritization, it is essential to be aware of these biases and be able to manage them within yourself and others. Here is a large chart created by designhacks.co that categorizes and highlights frequent known biases. 

This is too much information to keep in my head at once. I do know some people who keep a chart like this hung up in their office so that they can keep them in mind. I need a simple rubric to use, like a spec gauge, when new ideas are presented because the chart is too much for me to remember. When I hear a new idea, I want to make sure that it isn’t because of the person speaking it, my emotions about it, or to be fooled by numbers. 

BEAD 

Benefit 

Evidence

Already a solution

Demand

Benefit: If you build something, what is the benefit? This includes monetarily valued value, but it also refers to the user’s benefit. Often, a benefit can sound cool, but it might be a detriment when you consider what the user will do with it. 

Evidence: Do you have evidence that backs up the idea? Most stated ideas are untested hypotheses, meaning, “I think this will benefit our users,” but have we checked with them for their initial feedback on our idea? Sometimes, we find out our users are using our product in ways we hadn’t predicted, and our benefit would be a detriment. Even if we can articulate the value and benefit in a vacuum, we need evidence.

Already a solution: Even if there’s a benefit and evidence, why does a customer need this? Is it possible that they are already solving this problem? Is our proposed solution better than their existing one? 

Demand: So even if there’s a benefit, we have evidence that they would use it, and it would be better than what they’re using now. Is there demand, meaning, “I sure could use a brand new car,” but with the price of cars right now, I don’t have much demand? Demand factors in cost.

Example

A common problem I see now is related to AI. Many people want to introduce AI into their products, and in some cases, it’s hugely beneficial. But at what cost to the company and the consumer? I’ve seen several companies take their documentation and put it into AI. Let’s use our BEAD rubric on this. 

“Is there a benefit?” 

• Yes, the customer can ask the AI questions about the product and get answers. “

“Is there evidence?” 

• It’s important to ask customers why they would use AI instead of the search that has already been provided. Have you received complaints about the search not finding the correct information? Are people ignoring the documentation? Would they not ignore it with AI? 

“Is there a need already being addressed?”

• If they’re using search but need help finding the information they need, AI may not be helpful and could even be detrimental. AI has a bad habit of providing false information, so it is vital to ensure it doesn’t respond to the user with things the product cannot do. Additionally, if the AI says something is available, you may be responsible for delivering that to your customer.

“How may this impact demand?”

• The cost of AI is a factor to consider as well. Every AI query comes with a price. If you’re using one of the GAI models and building on top of it, it will cost you money from the vendor and your computing costs. AI is not free and is more expensive than search by a large margin. We all have scarce resources when trying to improve or build new products, so it’s worth asking if customers would pay extra for AI rather than search on your product page. Many price-inelasticity products should avoid adding AI because its increased costs could cause a drop, not an increase in demand. Is there something more important to the customer? Perhaps the documentation is needed because of a bad user experience. Investing in improved user experience may be the higher value solution even if AI is exciting, cool, new, etc. 

Final Thoughts

I like the acronym BEAD because it aligns with a powerful and simplistic adage my dad, who grew up on a farm and was used to firing a gun, told me about project management. 

To be successful in anything it is like shooting; one must follow the sequence: ready, aim, fire. Sadly, many folks tend to skip a step or mix up the order. They often fire before they’re truly ready or, worse yet, forget to aim altogether.

Jim Houx Jr.

In English, when you want to concentrate on something closely or define it accurately, you can say you’re “getting a bead” or “drawing a bead” on it. This phrase has its origins in the past when the small metal bump on the end of a gun barrel was known as a “bead.” The bead helped the shooter to aim at a target with precision. Using the BEAD acronym is part of my project management aiming process.