I claimed last week that one way to modernize a business process is to establish a system of record. And so I was thinking about systems of record, and why they are important. One big reason is that they help prevent fraud. At least that’s true of the system of record for accounting. Does that hold up when we start thinking about the system of record for product management? I think it does.
What does “fraud” mean in the context of product planning and decision-making? I think it means making decisions that either go against the data and information you have, or that are guesses because you haven’t done your customer development and all the other product management good practices. If you’re just making guesses, then you’re committing fraud on the investors. ([tweetthis hidden_hashtags=”#prodmgmt”]If you’re just making guesses, then you’re committing fraud on the investors.[/tweetthis])
The problem with the product world is that even if you do everything right, there’s still a high chance of failure. But if you don’t do things right, you’re more likely to fail. It’s like when you’re building a building – if you ignore the laws of physics in your design, you might have a beautiful building, and you might even be able to build it (depending on how far off you are from the laws of physics) but eventually the building is going to fall down, catastrophically.
How does the system of record fit into this? In two ways:
- It captures the results of your good practices – conversations with customers and prospects, insights from the markets, etc.
- It allows you to use those explicitly to support your decision-making.
Coming back to the baseball metaphor I used when talking about “chunks of value,” the system of record is a bit like the box score for the product management game. You can always go back and see what actually happened, and make sure your decisions are aligned with what’s going on in reality.
This is exactly why I argue that even in the Agile world, it is important to have key documentation around the marketing requirements up front, that are circulated and agreed to.
All too often I see the Agile methodologies being stressed into the "this means we don't have to plan" anymore. While I struggle at times to fully document what I want an end product to look like up front, I always find it useful as the program progresses as a yardstick, and a reminder to re-direct towards the end goal.
Thanks for the comment! I completely agree. It's hard (impossible?) to get the plan/design correct up front, but if you don't attempt it, you're going to end up with a mess. Like Eisenhower said, "The plan is nothing, but planning is everything." As long as you have the flexibility to rework the plan/design as you go, to respond to what you learn as you learn it, you'll be better off.