I was recently trying to determine the value of building a P&L for some development projects. Concerned that it might end up being a time sink that doesn’t pay off in the end, I asked a mentor of mine for his thoughts. Here’s his reply:
I think if you approach the per project P&L with a big grain of salt, it can be a very useful tool. The grain of salt = your P&L will never be precise and you get diminishing returns past a certain point. Your instinct about using rough numbers and not spending much time is right on, and in fact I’m guessing you wont be able to find much of the accounting info you’d want so you’ll be left making some reasonable assumptions (read: guesses) into your model. Before you’re done, you’ll have a bunch of numbers that are not at all “accurate” but are very useful for getting a ballpark sense of the world. That ballpark can help you and the team make decisions as well as look for things that are extreme corner cases that you might be overlooking. As you note, this model could also be useful for evaluating your backlog and again you’ll just be using educated guesses about features::business performance. You don’t have to know exact numbers to answer “does this feature help us sell more? is it a little or a lot? does it help us renew the customer? etc” and the model will help you have a framework for thinking through those questions.
I think there might be some sensitivity to calling it a P&L. Instead maybe “business case” or “pro forma project financials” something like that. I’ve also seen people get very sensitive about actually quantifying expense of employees, especially if its a team that isn’t used to a lot of accountability. Just some things to consider.On a side note, this could also help you spotlight the “one off” stuff you might be doing per customer deploy. That kind of stuff while sometimes necessary is a very dangerous, slippery slope and you’ll feel the pain first as the person responsible for the product. By definition, one off features are not scalable and don’t improve the overall product.
Ideally you as the product manager would say “no” whenever you see one. That’s usually not how things work, but having this model and a sense of the cost of doing a one off – in time, $, even feature trade offs – can help you start making the case to say no.
– Eric Wu (@ewu on Twitter)
This struck me a spot on, so I figured I’d share it. Hope it’s useful.