In our continuing series on managing the risk in your backlog, we look at the risk of kidding ourselves. Specifically, we use cause and effect and hypotheses to identify the assumptions in our plans, but if we don’t do it the right way, we will lie to ourselves by validating our assumptions instead of responding to the truth when we see it.Continue reading Motivated Reasoning and Validating Hypotheses
When deciding how to invest in your product, you need to take into account the risks that your investments will not return the outcomes you desire. One class of risks is business risk, and in product management we can influence the business risk of invalid intentionality – what I could call “building the wrong thing.”Continue reading Cause & Effect and Product Risk
There is a lot of advice out there for how to write requirements. There is not as much discussion about why to write requirements. Spend some time thinking about why you write requirements before you make decisions about how to write your requirements.
There are several ways to answer the question “is agile cheaper than waterfall?” Here are two of my favorites:
“It depends. Agile done well is cheaper, as long as you measure correctly.”
“You’re asking the wrong question. The right question is: is agile better?”
Is your team focusing on the mechanics of creating good software, without understanding the connections from your efforts to your goals? Are you primarily focused on the structure of use cases, the syntax of user stories, and the cardinality of your domain diagrams? All of these things are important to effective communication – but if this is your primary focus, you may be in a cargo-cult environment.
Wrapping up the your product failed because you didn’t enable your users to realize value branch of the root causes of product failure, is this article on the context in which your user is using your product. If you ignore your user’s context, they won’t be able to realize the value you provide – or won’t be interested in solving those particular problems at that particular time.
This article continues the series exploring the root causes of product failure. Even when you target the right users, and identify which of their problems are important to solve, you may still fail to solve the problems sufficiently.
Having an outside-in bias as a product manager is important – you need to understand how your customers (or your customer’s customers) would value capabilities you might build into your product. When running a workshop to collect that information, playing some “serious games” is a great way to get more and better information. We ran a few 20/20 Vision games last week, to great effect.
After building an understanding of which problems are important to your each customer you want to serve, and rating each competitive product , you’re ready to tally the scores and see how your product compares with your competition. This tells you if you’re likely to crush it, and if not, lets you know where you should invest later. This series on comparing products starts here if you need to get caught up.
And now, on to the finale…
A picture is worth a thousand words. A prototype is worth a thousand lines of code. Two key elements of product management – and of agile development are elicitation and feedback. Low fidelity artifacts can significantly improve both. Polished, codified prototypes can create problems that prevent you from getting the benefits of communication.