Mik Kersten pulls no punches about the Age of Software. In his book Project to Product, the Tasktop Technologies founder makes his stance on digital disruption clear: “No sector of the economy is safe.”
Digital transformation is top of mind for organizations seeking the competitive advantage as software becomes ubiquitous in nearly every aspect of business. Yet there’s a common disconnect between business and IT that can derail digital transformation before it begins. How can IT and business become better aligned as technology is developed to serve business goals?
To this end, Kersten suggests focusing on the “flow framework” of product management, rather than the linear, start-to-end approach typical of project management. The essential ideas behind moving from project to product are to measure your success based on business outcomes instead of delivery of a predefined scope, and profitability rather than costs. It’s all about ensuring that value flows to the customer.
One reason product orientation so successfully bridges IT and business is because it incorporates the Three Ways of DevOps — flow, feedback, and continual learning — into the management framework. This approach ensures your flow is able to evolve with changing requirements at any point during a digital product’s lifecycle.
A recent survey by Gartner indicates about 55% of IT organizations are shifting attention from projects to products. If you’re still not ready to start saying “product managers” instead of “project managers,” consider these seven crucial areas where product-oriented management has the lead on traditional project management, as defined by Mik Kersten.
Project to Product: 7 Impact Areas
1. Budgeting
Project: Projects have a fixed scope and fixed budget, usually front-loaded at the project’s inception. Because spend is typically capitalized, business stakeholders are incentivized to ask for all the functionality they think they might eventually need, leading to large and bloated project budgets, and project scopes.
Product: Invest funds for product value streams based on expected business results. Let demand, not speculation, justify additional funding, and focus on making incremental gains. Something to consider: How much trust is there currently between your business and IT managers? This level of transparency isn’t easy to achieve if both sides are unwilling to communicate. If distrust is breeding opacity, give your culture a longer look — it may be holding back innovation.
2. Timeframes
Project: Projects follow linear paths to an endpoint: launch. There is a prevailing assumption that, once launched, a software product goes into maintenance mode, needing much less attention. Maintenance often gets outsourced to a new team, distancing the project from its original developers — the experts.
Product: Product-focused management caters for continual improvement throughout the product lifecycle, rather than two distinct phases of “development” versus “maintenance.” A product’s ongoing health requires more than maintenance: It requires continuous improvement to ensure it stays optimized for achieve evolving business goals.
3. Success
Project: Focus is placed on whether the predefined project scope and deliverables were completed without exceeding the budget.
Product: Success is measured by looking at profit, rather than cost. Profit is a direct result of successfully achieving the intended business outcomes of the product.
4. Risk
Project: Because projects are scoped and budgeted upfront, risk is front-loaded in project management. However, software is changing all the time, and it’s impossible to know what challenges you’ll meet once development begins, let alone once users start adopting your solution. Projects become high-risk all-or-nothing gambles — often ending in failure.
Product: Managing products is a highly iterative process. This lets you avoid sinking costs in too many unknowns and, if need be, revise or end a product that’s not generating results. There’s still risk in product-oriented management, but it is managed continuously throughout the product lifecycle, rather than at its beginning.
5. Teams
Project: Project managers define fixed milestones and deliverables, and then assign a new development team to that work. Technologists are treated interchangeably and work on many projects.
Product: Build expertise among closely-knit teams who remain with a product for its lifecycle — or multiple teams for much larger systems.
6. Prioritization
Project: Requirements are delivered in succession according to the project plan, making changes difficult and expensive. These cascading steps encourage waterfall development, which isn’t ideal for projects like software that lack predictability.
Product: Hypotheses are created and tested, and each segment of development only goes as far a product can deliver value to the business, and thereby validate a hypothesis. Development is agile — flexible and lean.
7. Visibility
Project: IT is what Kersten calls a “black box”: There’s minimal transparency or communication between business and IT until the project is completed. Neither side is aligned and discrepancies between the two come only to light when it is too late and a lot of money has already been spent.
Product: Because of the continuous emphasis on hypothesis testing and measurement of business results, IT and business have to stay in sync. Business knows what IT is doing and why — and vice versa.
Bridging the Business-IT Gap for Digital Transformation
Product-oriented management keeps IT aligned with business outcomes and gives you the agility to ensure the software products you are developing (whether they’re internal digital tools or customer-facing) will serve your business objectives.
Digital transformation doesn’t need to be a struggle. JourneyApps can help you thrive in the Age of Software. Get in touch today.
