Being Wrong vs. Being Late

Which is the bigger risk for your product right now? Shipping with a feature your customers don’t value? Or delaying your release in order to ship with something they do value?

User Feedback vs. Deadline

I recently answered a LinkedIn Pulse Question – “How would you navigate incorporating user feedback when facing tight deadlines for product releases?” https://www.linkedin.com/advice/1/how-would-you-navigate-incorporating-user-feedback-as3kf?trk=cah2

I feel this question needs more visibility, and a bit more discussion than we can have in 750 characters in that section of their site, so I’m expanding my thoughts here and digging into some of the context of why this isn’t a trivial question.

Business Agility

I define Business Agility not in terms of process cadence, but in terms of three characteristics of how a company operates. If you don’t have all three, you’re not agile, regardless of how you manage your projects. If you disagree, I’d love to discuss it with you. I’ll be at Agile2024 this week – and you can probably find me near the C4G booth most of the time. Or start the discussion here or in the comments on LinkedIn when I share this post.

Three Non-negotiables of business agility

1. You have to create opportunities to learn within your process. Having an opportunity to incorporate user-feedback is a great example.
2. You have to perform the activities which generate learning during those opportunities. Asking users for feedback is an example. Many teams don’t do this or don’t know how to do this well.
3. You have to update your approach when you learn something. This is the pressure-point where far too many organizations get in their own way, unwilling to change the plan.

Risk Management

The pulse question, about how to deal with new information in the face of a tight schedule is something which pokes at the third characteristic. The implication of this being at the top of the list on LinkedIn Pulse is that this is a decision people don’t know how to address. I have a point of view – this is a risk-management decision.

You are balancing the risk of being wrong, with the risk of being late. And you have to decide which is worse. When raising our daughter, I would sometimes say “you have to choose your hard.” When you don’t do one thing which is unpleasant, it often comes at the cost of dealing with some other unpleasant thing. Cause and effect. So decide which one is worse and make your choice.

An economic analysis of the decision is reasonable, but people often screw it up. Estimating the cost of being late is something we have well established models for. We use the cost of delay to calculate the cost of delaying a ship-date. A mixture of delayed cash flow and lost revenue makes up the mechanisms of opportunity cost in this decision. People can develop what feels like a concrete assessment of the cost of shipping late.

There’s a minor issue in that by presenting the findings as a calculation, it engenders a sense of false precision in the analysis. Really, there is a range of uncertain consequences associated with schedule delays – between uncertainty both about the impact of, and the magnitude of the delay. That’s a thread worth pulling another time.

The major issue is in the other evaluation. What’s the cost of being wrong? This is so much significantly harder to assess that most people just don’t do it. My sense from working with so many teams focused on efficiency (at the expense of considering effectiveness) is that they don’t even consider this as a criterion for success. With an output-orientation, you win simply by shipping. “Did it work?” is a question you don’t even ask. And in too many organizations, “did it work?” is an unwelcome question. It is too uncomfortable.

Making this decision is problematical – comparing an ill-defined cost of being late with an undefined cost of being wrong. Too many teams pretend that “undefined cost” is the same as “no cost” and just choose to keep the schedule.

For those teams, the plan has become the goal. What happened to the goal?

I start building my model of the cost of being wrong with the premise – “no one will buy the wrong product.” This is both extreme, and wrong. Some people will buy it. But instead of asking people to share their beliefs about how many sales (relative to the established expectation) will be lost from shipping the wrong product, I ask them to explain how anyone buys it.

This is actually useful, because “wrong” is not a binary attribute either, but rather something much more nuanced. You have to genuinely look at the customer feedback, and then decide how this will affect your business model. Will ignoring this cause you to lose renewals or attached sales, driving customer lifetime value down? Will you miss out on referrals and organic growth through word of mouth? How many people are there who would buy if you address this but would not buy if you don’t?

All of this is uncertain, and you need to express your beliefs as estimates and ranges. But now you are at least making a decision comparing two ill-defined costs. You’ve levelled the playing field. You can make this decision well. Which now allows you to consider investing to improve the quality of future decisions.

Getting Help

This is the kind of stuff I help teams do, if you’re new to me and someone shared this with you. If you want help solving these problems, reach out and let’s discuss how best to make an immediate improvement.