If you are a project manager that does software projects, you deal with the “top side” of product investment all the time. Whether your teams are running agile like scrum or kanban, or whether they are running a phase-gated cycle (waterfall), you are focused on the decisions about organizing the investment into packages for release or deployment. You are running the factory which takes requirements in one end and (hopefully) spits working features out the other. You are working with the analysts or product people to ensure that there are enough requirements, stories, or ideas “ready to start” to keep the team occupied.
But what about the other side of product investment? We often talk about return on investment or ROI, but most organizations only use an ROI project to justify the investment. Some will go as far as to attempt to measure “hard” ROI numbers, but frankly even that is missing half the boat because it is hard to measure the impact of software capability on your organizations top line or bottom line. Without a body count, the best we can do is to infer the correlation of software capabilities to a movement in profitability and assume that the relationship is causal. When it comes to softer benefits like risk reduction, customer satisfaction, or employee retention, there is no reasonable way to measure “hard” ROI dollars.Continue Reading
At the core of every software product road map are two concepts. These are essential to all software product development. We may think of different things, and we may use different terms or even look at them from different angles but at the end, I am convinced that it boils down to only two things:
Capabilities and Adoption.
in my experience, every other thing we do when we build software is a component, or is connected to one of these concepts. I think often that what gets us screwed up, is that that we focus on the “every other thing” from some methodology, or some playbook, or some consultant, and lose the plot on the essentials.Continue Reading
This post is an extension of What Did The Boss Say. In that post, we explored why executives and managers tend to want a single point of control or responsibility, as well as some of the things that must be delegated to that single point. But there are disadvantages to the single point strategy.Continue Reading
Continuing down the path of understanding the differences between contemplation of project vs product as the center of our software universe.
Here are a few pithy aphorisms:
- The resources expended during a project are the cost of the product created, not its value.Continue Reading
Agile thinkers focus on the product – and how we are intentionally adding value to a “software asset” and potentially how we manage our “portfolio” of software assets. Phase-Gated Delivery (some people call it waterfall) patterns allow us to “optimize” the work against the constraints – but do not allow us to optimize the value delivery in time. In fact, they push ALL the value delivery to the very end of the cycle. But in theory, because we can optimize the projects by minimizing the schedule and cost against a constant value output – the value can be had for less investment. Problems arise when – the actual value is realized over time (meaning the sooner the customer has access to a software capability, the sooner his actual costs go down or his profits go up).Continue Reading
What is the purpose of a product organization? Thinking generally, it is to increase the value of a product “in the eyes” of the customers, consumers, or users of the product. It doesn’t matter whether the product is toilet paper or software.
The product manager has decision rights over what the product will become.
The product organization manages a portfolio of products, and the purpose of portfolio management is usually maximize the value of the portfolio. How they do this job depends largely on the products and the organization that sponsors them.Continue Reading
Product Management is something that should be easy to understand. The highest level goals of product management should be easy to articulate.
1) build a valuable product
2) maintain the value of a product relative to its customer community
3) manage the investment in the product, to ensure the best possible returnContinue Reading
I work in an environment that is somewhat dominated by a project governance mentality. What does this mean? What it means to me is this – that our diligence is focused on spending rather than on asset creation. Why is this significant? Because it changes how we focus the decisions in the process of software development.Continue Reading
If you want to manage a portfolio of software products, it is necessary to understand the organizational goals that are met by those software products. The product portfolio is a vehicle for understanding the ongoing investment in development or deployment of software assets. It requires an ability to measure the value of software assets separate from their cost (rarely done in industry today), and an ability to measure the cost of ongoing support and maintenance of software product. Continue Reading
Why is it that the customer in corporate software projects seems to want to pack the scope of every project with capabilities of dubious value, in the same way that our congressional leaders try to pack important bills with “pork”? Why do organizational leaders try to take a well funded project or initiative and use it as a means of funding their personal management agenda? Because like congress, if they can construe their agenda as essential to the completion of some important project – they bring the business value (pork) home to their department. They can use the project as a vehicle to accomplish things that ensure that they get their bonus. These leaders act as though their incentives are more important than the overall health of the corporation – just like congressmen act as if their re-election is more important than the overall health of the nation.Continue Reading