-
Packaging Is More Than Pricing: Three Different Ways to Package an Offering

Introduction

When discussing products, services, and solutions, the word packaging is often used as if everyone understands what it means. In reality, different stakeholders mean different things when they talk about packaging.
A sales leader may think about commercial bundles and discount structures.
A product manager may think about predefined offering scopes.
A service business leader may think about combining products, services, software, and expertise into integrated customer solutions.
And all of them are correct. The problem is that we often mix these discussions together.
Through my experience in product management, service business development, and offering management, I have found it useful to think about offering packaging on three distinct levels:
- Commercial Packaging
- Scope Packaging
- Value Packaging
Understanding the difference helps organizations make better decisions about offering development, commercialization, and portfolio strategy.
Level 1: Commercial Packaging

Commercial packaging focuses on how the offering is bought.
The actual product or service may remain unchanged, but the commercial structure is designed to increase purchasing attractiveness, simplify procurement, or improve profitability.
Typical examples include:
- Buy three, get one free
- Subscription models
- Volume discounts
- Bundled pricing
- Fixed-fee agreements
- Loyalty programs
Many organizations start their packaging journey here because the implementation is relatively straightforward. Commercial packaging can generate immediate sales benefits and improve customer adoption. However, commercial packaging alone rarely creates sustainable differentiation. Competitors can usually copy pricing models faster than they can copy capabilities.
Strategic bundling research highlights that effective bundles create additional perceived customer value beyond simply grouping products together. Strategic bundling succeeds when customers experience a more complete solution rather than just a discounted collection of items. [verhaert.com], [bing.com]
Level 2: Scope Packaging

Scope packaging focuses on what the customer gets.
The objective is to create clarity, consistency, and scalability.
Anyone who has worked with large service organizations knows the challenge:
Sales teams want flexibility.
Customers want customization.
Operations want standardization.
Scope packaging is where these competing needs meet.
Common examples include:
- Essential / Professional / Enterprise
- Standard / Advanced / Premium
- Assessment / Implementation / Support
- Bronze / Silver / Gold
The goal is not to reduce customer value. The goal is to create repeatable delivery models that are easy to understand, sell, and deliver.
Good scope packaging creates transparency for customers and reduces internal complexity.
Poor scope packaging creates confusion, overlaps, and endless discussions about what is included and what is not.
Level 3: Value Packaging

The most strategic form of packaging is value packaging.
This is where organizations stop thinking about products and services as separate entities and start thinking about customer outcomes.
The question changes from: “What should we sell?”
to: “What outcome is the customer trying to achieve?”
Examples include:
- Equipment + Maintenance
- Spare Parts + Predictive Analytics
- Training + Advisory Services
- Product + Software + Lifecycle Agreement
- Outcome-Based Service Contracts
Instead of buying multiple individual offerings, customers purchase a solution designed around their business objectives.
I would argue that value packaging is where the real strategic advantage exists.
Products can be copied. Services can be copied. Pricing models can be copied. Integrated customer value systems are significantly harder to replicate.
Why Portfolio Leaders Should Care?

This topic is not only relevant to product managers or commercial leaders. It is highly relevant for portfolio leaders. Many organizations govern products, services, software, and development initiatives in separate portfolios.
The customer, however, does not see separate portfolios. The customer sees a combined offering.
This creates an important portfolio management question:
Are we managing components, or are we managing customer value?
The future winners will likely be organizations that can manage portfolios across organizational boundaries and package capabilities around customer outcomes rather than internal structures.
Final Thoughts
When organizations talk about packaging, they often focus on pricing. When they mature, they focus on predefined scopes. When they become truly customer-centric, they focus on customer value.
Perhaps the most useful question for management teams is not:
“How should we package our products?”
But rather:
“How should we package value?”
Because ultimately customers seldom buy products. They buy the outcomes those products enable.
Further reading
Kohtamäki et al. (2019). Digital Servitization and Product-Service-Software Systems.
Cooper, R.G., Edgett, S.J. & Kleinschmidt, E.J. (1999). New Product Portfolio Management: Practices and Performance.
ITIL 4 Service Offering Model (Goods + Access to Resources + Service Actions)
- ITSM Professor: What Is a Service Offering?
- ITIL 4 Service Offering Overview: Service Offering in ITIL 4
Harvard Business School
Strategic Bundling and Customer Value Creation
- Verhaert: Discovering Value and Growth Through Smarter Bundling
- LeveragePoint: Realize Value from Product & Service Bundles
-
Why B2B Customer Journeys Belong on the Strategic Portfolio Agenda?

In many organizations, customer journey management (CJM) is still treated as a CX, service design, or marketing initiative. Journey maps are created, workshops are run, and insights are generated – yet impact at scale often remains limited.
One clear message from academic research and industrial case studies is this:
B2B customer journeys are not operational details.
They are strategic assets – and should be managed as such.This post summarizes 10 key lessons learned from B2B customer journey research, drawing directly from MBA thesis work and recent literature, and translates them into strategic portfolio implications.

1. Customers don’t experience touchpoints – they experience journeys
Organizations often optimize individual interactions because they are measurable and owned by single functions. Customers, however, evaluate their experience cumulatively across the full journey.
Research shows that end‑to‑end journey satisfaction explains loyalty and growth better than isolated touchpoint KPIs. Improving one step does little if the journey breaks between steps.
Portfolio implication:
Strategic investments should be assessed based on journey impact, not local efficiency gains.References: Rawson et al. (2013); Lemon & Verhoef (2016)

2. B2B journeys are long, complex, and non‑linear
B2B customer journeys differ fundamentally from consumer journeys. They typically:
- span months or years
- involve repeated lifecycle cycles (sales, delivery, service, renewal)
- include multiple stakeholders interacting at different phases
Linear funnel thinking does not hold.
Portfolio implication:
Strategic portfolios must support lifecycle thinking, not one‑off project logic.References: De Keyser et al. (2025); Homburg & Tischer (2023)

3. One weak stakeholder journey can derail the entire relationship
In B2B, “the customer” is rarely one person. If a single key role – for example procurement, finance, or operations – experiences friction, the overall relationship suffers, even if others are satisfied.
Portfolio implication:
Journey investments must explicitly address all critical personas, not just the most visible ones.References: De Keyser et al. (2025); Pruitt & Adlin (2006)

4. Journey mapping reveals problems organizations don’t see
Journey mapping research repeatedly uncovers:
- missing touchpoints
- unplanned detours
- handover failures between functions
Many of these issues remain invisible in traditional cost, productivity, or SLA metrics.
Portfolio implication:
Journey insights should inform where to invest, redesign, or stop initiatives, not just inspire workshops.References: Halvorsrud et al. (2016); Følstad & Kvale (2018)

5. CJM works only when treated as an organizational capability
Successful companies treat CJM as a capability, not a project. Research identifies core dimensions such as:
- value anchoring of interactions
- consistency over time
- cross‑functional integration
- tailored control for different roles
These capabilities must be built and sustained.
Portfolio implication:
Some investments are capability‑building plays, not quick ROI cases – and should be evaluated accordingly.Reference: Homburg & Tischer (2023)

6. Organizational silos are the number one obstacle
Most CJM initiatives fail not due to lack of tools, but due to:
- fragmented ownership
- disconnected data
- local optimization incentives
Journeys cut across organizational boundaries by definition.
Portfolio implication:
Portfolio governance must address cross‑functional ownership, not reinforce silos.References: Rawson et al. (2013); Dhebar (2013)

7. Leadership and governance determine success
CJM research consistently highlights the role of leadership. Without:
- executive sponsorship
- clear journey ownership
- aligned metrics and incentives
journey initiatives stall or remain local experiments.
Portfolio implication:
Customer journeys are a leadership agenda item, comparable to major transformation themes.References: Rawson et al. (2013); Homburg & Tischer (2023)

8. Data shows what happens – journeys explain why
Analytics identifies where customers drop off or struggle. Qualitative methods explain the reasons behind the numbers. Neither is sufficient alone.
The strongest CJM combines journey analytics with human‑centered insight.
Portfolio implication:
Investments in data platforms should be paired with investments in interpretation and sense‑making.References: Halvorsrud et al. (2016); Davenport & Klahr (2018); Salminen et al. (2018)

9. Journey‑level metrics outperform touchpoint KPIs
Traditional KPIs often hide the real customer experience. Journey‑level measures, such as end‑to‑end satisfaction, are more predictive of churn, loyalty, and growth.
Portfolio implication:
Decision‑making should be informed by journey outcomes, not only functional metrics.References: Rawson et al. (2013); Dixon et al. (2013)

10. CJM pays off – but it must be managed consciously
Research confirms that strong CJM capability improves customer loyalty and financial performance. At the same time, it can increase coordination effort and short‑term complexity.
The benefits are real – but not accidental.
Portfolio implication:
Customer journey investments need explicit prioritization, trade‑off decisions, and governance, like any strategic asset.Reference: Homburg & Tischer (2023)
Final reflection
B2B customer journeys are not something to optimize at the edges. They are something to manage deliberately – at portfolio level.
When journeys are treated as strategic assets, organizations stop asking:
“How do we improve this touchpoint?”
And start asking:
“Which journeys matter most – and where should we invest, simplify, or stop investing?”
Selected references
- Homburg, C., & Tischer, M. (2023). Customer journey management capability in business‑to‑business markets. Journal of the Academy of Marketing Science.
- De Keyser, A., et al. (2025). Understanding the B2B customer experience and journey. Journal of Business Research.
- Rawson, A., Duncan, E., & Jones, C. (2013). The truth about customer experience. Harvard Business Review.
- Lemon, K. N., & Verhoef, P. C. (2016). Understanding customer experience throughout the customer journey. Journal of Marketing.
-
Product Strategy Demystified: How to get it Right?

Why do so many products fail despite great ideas? Often, the missing link is a clear, actionable product strategy. A good strategy isn’t just a roadmap – it’s a set of choices that connect vision to customer value and business outcomes. But how do you get it right? I will summarize both my own practical learnings and also add plenty of inspiring additional reading links below! As always, I hope this is helpful, and I would love to hear your thoughts, too!
Building ambitious and inspiring product vision

The first mindset shift needed is moving from day‑to‑day operational or tactical thinking toward a more strategic perspective – starting with your product vision. Ask yourself: Do you already have an ambitious product vision? Has it been created together with your team and aligned with management?
Below are a few practical tools that can help you define and strengthen your vision:
- North Star – What is the ultimate desired long‑term outcome for your product?
I’ve written about this earlier – here is a link for inspiration:
https://strategic-portfolio-management.com/2023/08/05/finding-your-north-star-creating-a-shared-long-term-vision/ - Bright Future Ahead – What does a compelling future look like for your product?
Read more here about the Bright future method which I have learned from my earlier colleague Mirette Kangas:
https://strategic-portfolio-management.com/2023/01/02/bright-future-ahead-creating-an-inspiring-development-portfolio-vision/
Whichever method you choose, define an ambitious and inspiring product vision—one that energizes your teams and guides strategic decisions.
Objectives and Key Results – Step-by-Step Path Towards Product Vision

One of my favorite tools for goal-oriented management is the Objectives and Key Results (OKR). It integrates well into a product strategy approach by helping you to set clear, step-by-step objectives and measurable key results that lead you toward your future vision.
The idea with OKRs is simple: we define inspiring objectives and concrete measurable key results. Sounds easy, but defining great OKRs requires some work and typically a few iterations with the team and key stakeholders. Over time, OKRs become better and better!
For more on OKRs, here’s an earlier blog post with helpful links:
https://strategic-portfolio-management.com/category/objectives-and-key-results/Where to Win and How to Play?

When you are developing your product strategy, DO NOT FORGET YOUR CUSTOMER!
Product strategy must be grounded in customer insights – understanding the real needs of customers.
- Based on customer feedback, what insights do you have for the future needs of the customers?
- Are you actively ideating with customers and validating new ideas with the customers?
- What is your product’s key value proposition towards customers? Can you summarize shortly how your product creates value for customers?
- Do you know your key customer segments – where do you want to focus efforts?
- How are markets evolving? What alternatives or competition do you have in the markets?
- How is your global supply chain looking like considering different geographical locations? Do you have different customer needs in different regions?
- How is the regulation changing? Do you have some compliancy requirements to consider?
- How about the strategy for the company or business unit? Do you receive new direction regarding the product focus areas from this strategy?
This is one of those topics, which for sure would deserve fully dedicated blog post…
Building an Outcome-Based Strategic Roadmap with Different Time Horizons

What is the first thought when you think about product strategies? For many of us, it may be a product roadmap illustrating where we are heading with the product and what developments are ongoing.
I have seen many wonderful product roadmaps, and here are a few options to consider:
- Build an outcome-based roadmap – instead of showing project stages or milestones, show what the tangible concrete outcomes of development activities are.
- Show different time horizons – build your roadmap utilizing different time horizons. For example, you could have a detailed roadmap for the next quarter or year, but less detailed business epics for the next five years.
- Build your roadmap based on strategic themes – group development activities based on strategic themes, to link the work to company or business unit strategy implementation.
- Utilize common roadmap templates – check with your colleagues, if they already have great templates or examples, you could utilize for your product roadmaps. If every product manager in a company builds the roadmap in a different way, think about the headache for senior management trying to see the big picture.
- Utilize company portfolio management tools – portfolio management tools today offer possibilities to create different types of views and visualization based on the entered data. If you have a tool available, could you utilize that to create portfolio level transparency?
- Share your roadmaps with the stakeholders – If you do not have common tools, would you have a common location where to store and share product roadmaps? If your product roadmaps cannot be openly shared across wider group of stakeholders, do you have regular meetings where you share the updated roadmaps with the management?
Building a great product roadmap typically requires several iterations – you may need to collect feedback from different development teams and numerous stakeholder groups – and based on all of the feedback received, you can improve your product roadmap. Just remember to utilize your product roadmap actively as a part of day-to-day work when you meet different stakeholder groups!
What is the lifecycle phase of your product?

Product strategy depends a lot on the lifecycle phase of your product. I have noticed that for a wider group of stakeholders, it is not necessarily clear that everyone shares the same understanding of the stage. Sometimes, a product may still be in pilot as part of New Product Development, but there is an expectation of already reaching growing volumes. Your organization may have its own categorization for product portfolio management, but here is a generic one with phases: 1) New Product Development, 2) Introduction, 3) Growth, 4) Maturity, 5) Decline.
Here are few topics to analyse:
- In which lifecycle phase is your product currently? You can also use volumes and sales statistics to analyze this if it is not fully clear, and have an open discussion with the team and stakeholders.
- Are you moving towards next phase and do you need to take actions to prepare for the next phase? For example if you are moving from New product introduction to Growth phase, do you have scalable service processes in place to support growing volumes?
- If you are looking at the product portfolio, how does the overall status of different products look like? Do you have gaps in your portfolio?
- Are you familiar with Strategyzer’s Explore and Exploit portfolio? Good content piece to check out available here: https://www.strategyzer.com/library/business-model-evolution-using-the-portfolio-map
Share your product strategy to build alignment and feedback loop

If you create a great product strategy, but only a few people know about it – product strategy creates little value. So be brave and share your product strategy with the stakeholders – it may feel very uncomfortable especially during the first rounds, but it gets easier over time.
- Implement feedback loops – product strategy should evolve with market shifts, technology changes, and based on customer feedback. What is the good cadence for you to look into product strategy? Quarterly? Bi-yearly? This depends a lot on what type of product you are working with.
- Our teams have had good experiences with product strategy days with the key stakeholders and strategy communication towards larger audience.
- Customize communications content based on the audience – Sometimes it is a good to remind myself, that not everyone is deeply involved in our product development, and you may need to have communications materials with different abstraction levels. If you have a master comms materials, pick and choose relevant content to meet the needs of your audience.
What are your pro tips? I would love to hear what has been working well for you!
For more inspiration – additional reading
There is a lot of really good content about product strategies, here are few examples I have felt were inspiring:
Aha! (2025). Product strategy: How a clear one leads to success. https://www.aha.io/roadmapping/guide/product-strategy
Amplitude. (2024). What is a product strategy? Framework, template, and examples. https://amplitude.com/blog/product-strategy-framework
Atlassian. (2025). What is a product strategy? Definition, best practices & how to build one. https://www.atlassian.com/agile/product-management/product-strategy
Design2Market. (2024). Product strategy demystified – No MBA required. https://www.design2market.co.uk/academy/product-strategy-a-step-by-step-guide/
ProductPlan. (2024). What is a product strategy? https://www.productplan.com/glossary/product-strategy/
Remote Sparks. (2025). 10 essential product strategy frameworks for 2025. https://www.remotesparks.com/product-strategy-frameworks/
Scrum.org. (2025). What is product strategy? How to think and act strategically as a product leader. https://www.scrum.org/resources/blog/what-product-strategy-how-think-and-act-strategically-product-leader
Walker, S. M. (2024). Product strategy guide — Templates/Frameworks (2023 Edition). https://productstrategy.co/the-ultimate-guide-to-product-strategy/
- North Star – What is the ultimate desired long‑term outcome for your product?
-
What is the correct level of productisation?

The goal of productisation is to create a product that is easy to sell, deliver, and scale. Easier said than done, right? I will summarize some of my own learnings from the development of digital solutions, hardware-based products, and service concepts, and include insights from the literature as well.
Starting with WHY…
It is always good to look at the benefits first, as productisation work requires time and effort. Here are few commonly identified benefits as a food for thought:

Scalability & Revenue Growth: Productised offerings are easier to scale to meet increasing demand and can open new revenue streams through higher volumes.
Efficiency of Operations: Repeatable processes reduce hassle and shorten lead times for sales, delivery, and operations.
Marketability: A well-defined productised offering with clear value propositions is easier to brand and promote.
Consistency via Standardization: Standardized products ensure consistent quality and customer experience, which can enhance customer satisfaction.
Competitive Advantage via Differentiation: A clearly defined productised offering can help differentiate from the competition.
What would be the benefits in your context?
What do you mean? We have done productisation for years…
The term “productisation” can have various meanings depending on the context. Therefore, it is beneficial to begin discussions by clarifying what each participant considers a productized solution – and what would be the desired level of productisation for this specific product. This is a good topic to discuss with the group of stakeholders also when you are updating the product strategy next time!
If the scale is from fully customized to fully standardized, where is your product in the following scale? Where would you like to be in the future?

When the offering is targeted at a specific niche customer group and there is no aim to scale the product to high volumes, a lower level of productisation may be sufficient. On the other hand, if you are aiming for a high-volume product, well-defined and scalable sales, delivery, and service processes will create significant value over time.
Another dimension to consider is the flexibility of offering options. For high-volume products, well-defined offering packages create clarity for customers and stakeholder groups. In a hardware-intensive environment, do you allow customer-specific engineering, or do you have predefined options? On the other hand, if you are working with consultancy services, offering packages may have high-level definitions, and the content needs to be customized based on customer needs. For standardized offerings, well-defined product data structures and maintenance processes also enable efficiency during the lifecycle phase.
Here are a few questions to help you identify the correct level of productisation:
- What volume levels are you targeting with this product?
- What level of flexibility are your customers expecting in terms of offering options?
- How much time, effort, and money are you willing to invest to productise the solution?
- What is the correct time to invest in productisation work in your case?
- Do you have good documentation in different areas to support the rest of the organization (technical, commercial, process documentation)?
- Do you need tool support and product data improvements, such as sales tools development and product data processes?
Productising services or servitizing products?

If you are working with physical products, productisation efforts may be quite different than if you are working with services. I like the triangle model adapted from article by Baines et al. (2007), visualising the need to servitize products and productise services.
For productising services, I have found useful the idea of developing service concepts, which have well defined processes, commercial models and the same service concept can be scaled up across different product and offering areas. If there processes for each service is different, services remain difficult to scale up, and productising of each service require a lot of time and effort.
For the product based offering with long life time, sometimes even decades, it is important to also develop the life cycle services, and servitise the product to ensure smooth operations, maintenance and possibility to upgrade the product. The work related to servitisation takes time and effort, and it is good to start to build service readiness in the early phases of development.
Hey, we are working with Software products…
Hopefully somewhat clear for physical products and service, but how about software products?
If you are working with software products, here are few supporting statements for evaluating the level of your productisation:
- Software can be easily deployed and maintained
- In addition to software, also installation guides, user manuals, and service support models are in place
- Consistent product brand with product naming, logo, marketing materials have been created
- Pricing strategy is reflecting the product value has been validated with the customers and well documented to support the sales
- Support models for software updates are in place, including processes for bug fixes and introduction of new features
- Software product is scalable for higher volumes enabled by sound architecture design
- There is a systematic feedback loop with the customers to continuously improve the product
What is your approach for productisation?
The next time you look into product strategy updates, would it make sense to have a discussion on productisation as well?

As always, I would be happy to get your feedback and thoughts for example via LinkedIn!
If you are interested, here is a list of good reading…
Armstrong, E. (2020). Productize: The Ultimate Guide to Turning Professional Services into Scalable Products. Productize Press.
Baines, T. S.; Lightfoot, H.; Steve, E.; Neely, A.; Greenough, R.; Peppard, J.;. . . Wilson, H. (2007). State-of-the-art in product service-systems. Proceedings of the Institution of Mechanical Engineers, Part B: Journal of Engineering Manufacture
Cagan, M. (2017). Inspired: How To Create Products Customers Love. Wiley.
Mironov, R. (2008). The Art of Product Management: Lessons from a Silicon Valley Innovator. Booksurge Publishing.
Olsen, D. (2015). The Lean Product Playbook: How to Innovate with Minimum Viable Products and Rapid Customer Feedback. Wiley.
Banfield, R., Eriksson, M., & Walkingshaw, N. (2017). Product Leadership: How Top Product Managers Launch Awesome Products and Build Successful Teams. O’Reilly Media.
-
10 steps to get started with your strategic initiative – Ready, Steady, Go!

Many organizations have well-defined project methodologies and today also agile practices; however, when it comes to large and complex strategic initiatives, one often needs to learn this part by doing. And for many, it is a rough road as up to 70% of strategic change programs fail [1]. Next blog posts will focus on good practices, how to get started with your strategic initiative, and how to avoid the most common challenges!
Why do strategic initiatives fail?

Let’s review key reasons why change programs fail, based on the study [1]. When participants in the survey were asked to create a list of reasons for failure, ‘insufficient budget’ was cited by 23% and – ‘insufficient time’ by only 17%. Instead, participants ranked poor communication (62%), insufficient leadership and support (54%), organizational politics (50%), lack of understanding of the purpose of the change (50%), lack of user buy-in (42%) and lack of collaboration (40%) as the most critical issues. Executive buy-in and sponsorship are also commonly cited as reasons for failure. Leading strategic initiatives is truly challenging, even though there are great people leading these activities, it is never easy!
What needs to happen to get started?

Getting started with a large strategic initiative can indeed feel overwhelming. Where do you begin, and what needs to be done? I understand the frustration all too well; one of my own development programs dragged on for seven long years before receiving approval. You’re not alone in this struggle!
There are established standards for project and program management, so I won’t write a guide on that. Instead, I’ll focus on the content and what usually needs do be done during the pre-study phase of a large complex initiative, whether you’re changing the operating model, transforming your processes and IT solutions or creating completely new type products and offering.
Hey, all you seasoned leaders and program managers out there! What 10 steps would you guys suggest? Here are the ones I think are the most crucial!
READY – Getting started with your strategic initiative
To get started what are the key things to focus on? I would start with the following steps:

1. Create an inspiring future vision
When you are in a hurry to get started, one may miss this part easily. However, without an inspiring future vision, you may lack the clear direction, north star, where you want to be in the future. Here are few supporting questions:
- Where do you want to be in the future?
- What would good look like?
- WHY is this change needed?
How to create your future vision? Couple of methods for inspiration:
- Bright Future Ahead – Creating an Inspiring Development Vision – Kudos for Mirette Kangas – who has been teaching this methodology!
- Finding Your North Star – Creating a Shared Long Term Vision
2. Analyze As-is state and define engaging To-be state
At the beginning of the journey, it is good to understand the current state from different perspective, but also define a concrete to-be state aligned with your future vision.
- Take some time to understand your as-is situation from different perspectives – where are you now? Look into different perspectives:
- How standardized your processes are, what are the skills of different roles and capabilities of the organization?
- How are the tools and IT solutions supporting the processes? How is needed data maintained?
- What is the state of art for your current technology, products and offering? How are the sales numbers today?
- Where do you want to be concretely to reach the future vision?
- Do you need to build new organizational capabilities to support the future vision? New roles or skills needed in the organization?
- Do you need new IT tools or enhance existing tools? Do you need more systematic data management practices?
- Do you plan to develop new products or offering? Do you have needed knowledge in the organization for development, or would you need external help or new hiring? Do you need to build new technical capabilities or develop new technology?
- If you plan to develop new type of offering, who would sell, deliver and operate? Do you need to develop end-to-end processes and supporting tools?
- What is the gap between the as-is situation and your desired future vision?
- Great ways to communicate about the gap is to define From -> To-be statements or create a systematic gap analysis
- Analyzing the current state and to-be state often requires help from many stakeholders – ensure you involve correct parties to start the organizational engagement!
- For large complex development initiatives, you can get started with a well prepared workshops, but typically some iterations are needed!
- The gap analysis is also excellent tool for initiative scope definition and planning the roadmap!
3. Secure strong core team and sponsorship
This is a step, you should not miss!
A strong core team is crucial to make things happen. You can achieve little alone, so building a committed team early with resource managers is essential for success. Here are few supporting questions:
- What type of skills you need in your team? Do you need for example end-to-end business knowledge, technical experts, IT gurus, or someone from the sales?
- Check out the organizational chart, who is responsible for different areas and seek for advice from people who know the organization and people very well.
- Do you need professional project management support or agile coaching? How about the change management and communications, who could take a role?
- Start to already think also a longer term plan – would you need new hirings with new skills or could you use external experts to get a quick start? Check out also what practices your organization have for headcount planning and approvals – so that you will not have surprises later on.
Senior management sponsorship is essential for any complex transformation, and without this support, the initiative will most likely fail. You need the strong sponsorship for driving the investment approval, you need the sponsorship to secure the best possible resourcing and you need the sponsor to support you to drive the change. Here are few things to consider:
- If sponsorship is clear from the day one, engage your sponsor already to create the future vision! Discuss with your sponsor about the expectations of the role, and also sponsor’s availability during the transformation journey.
- If your initiative has cross-unit impact, do you need multiple sponsors? In large corporations, do you need sponsorship from different levels of the organization? Do you have a sponsor and an owner?
- Perhaps your initiative is something completely new, where clear ownership does not exist – look upwards in the organizational chart – who should you reach out to identify the sponsor?
- If you fail to identify the true sponsor, is this an initiative organization has enough commitment to start with?
Steady – Plan and prepare!
Even though there are critical activities when getting ready, it is important to also start to look into the concreate plans and do a solid preparation. Let’s look into high level steps required here!

4. Define the scope and draft the roadmap
One of the challenges many complex strategic initiatives face is the creeping scope.
- Define concretely what is in the scope of your initiative, but maybe even more important is to clearly communicate what is out of the scope – to manage the expectations with the organization
- For roadmap definition, here are few tips to consider
- Are you structuring your initiative as a program including different projects, or do you for example have multiple working streams with smaller activities or is the development implemented by the agile teams and you would have epics in your roadmap? Reach out to your PMO or portfolio management team to get support for structuring the work.
- Are you able to create an outcome based roadmap? So that the reviewer of your roadmap can see what outcomes will be achieved.
- If your initiative is large and complex, do you need multiple roadmap views for different purposes? Higher level roadmap for the entire initiative duration, and more detailed one for planning purposes?
- Check also in the early phases, if you have portfolio or project management tools in use and could these tools help to visualize the initiative and create transparency across the organization.
- Roadmap and scope should be actively updated based on the learning as a team and also based on the stakeholder discussions. Also throughout the execution phase of your initiative, I would recommend to review and update roadmap at least quarterly.
5. Validate feasibility and analyze risks
At this phase, it is important to step back, and also do a quick validation of the plans and think about how to mitigate key risks. Here are again few supporting questions:
- First of all, your core team and sponsor should be committed to your draft plan – is your roadmap ambitious but still doable and realistic?
- Do you need new technology to support your initiative? What is the real readiness of the technology?
- What key assumptions you have taken while creating the roadmap? Write down the assumptions, and analyze if there are weak points.
- Do you have strong dependencies to other initiatives – what happens to your plans, if there are changes in the other initiatives?
- What are the key risks included – and how can you mitigate those? Check out your organization’s risk management practices to be compliant with those.
- Later on, when you review the plans with other stakeholders, pay attention to questions or concerns to identify still weak points. Improve your roadmap based on the feedback!
6. Prepare a solid business case
Well – this is the moment of truth – now that you have done initial planning, do you have strong solid business case? Here are few things which have been helpful for me:
- Partner with your business controlling to get the best possible support. Check out with your business controlling and portfolio management teams if there are templates or good practices to follow! Are there yearly planning cycles such as long range planning or budgeting as DLs to be take into consideration?
- What are the key sources of benefits? Are you aiming at saving costs or increasing the sales? If you are planning to increase the sales, seek for commitment from your sales colleagues – how do they see the sales potential in different regions? Are you able to start to deliver value incrementally? More tips here: Focus on Value!
- Look holistically into different types of costs elements – do you need Opex or Capex funding, do you need extra headcount during your transformation program – and what is the impact of development for the run costs? Check out also other viewpoints to business cases for an earlier blog: How is your development portfolio impacting future run costs?.
- Are there soft benefits – something you cannot measure easily in monetary terms, but are still creating value?
- Document also the assumptions behind, so that you can explain your numbers clearly. And sometimes also few scenarios may be helpful, for example with optimistic and a bit more neutral sales scenario.
- Some initiatives are also mandatory due to regulation, obsolescence management of technology or other reasons – communicate clearly these reasons, if you are not able to define a positive business case.
- Involve people with different perspectives to review the business and validate and iteratively improve the business case.
7. Define objectives
You may have a well established way for target setting and KPIs in your organization, and it is important to follow these practices.
- Seek guidance from your business controlling and sponsor – what would good look like in terms of inspiring objectives, and how you can measure the success?
- One of the powerful tools I would recommend to close the gap between the high level strategic vision and actual development is the goal oriented management – defining clear Objectives and Key Results: Closing the gap between strategy and development using Objectives and Key Results (OKRs)
GO – Get the approval!
Once you have done your preparations well, it is time for pre-cooking to get your investment approval!

8. Create a pitch deck
Create a clear pitch deck, you can use to support the decision making. Include the key information from the previous steps in the pitch deck. Here are few tips, which have been useful:
- Create a clear management summary – make it short and crisp.
- Make your pitch deck modular – you can pick and choose different slides for different meetings based on the stakeholder interest.
- If your organization has standardized template for investments, get familiar with what is required there.
- Don’t make it too long – add more detailed content in appendices.
9. Seek for alignment
In large organization, this is the part where you may either ensure success to be doomed to fail.
- Identify systematically stakeholders to align with. Ensure you have possibility to present your initiative in existing forums or organize own alignment meetings as needed.
- Book 1-1:s with key decision makers to get their inputs early enough – and based the feedback, improve your proposal. You want to avoid no-go decision due to poor pre-cooking.
- Sometimes there are different interests within large organizations – try to find win-wins – and also think about how to communicate about your initiatives to different stakeholder groups.
- In addition to your organization, do you have important partners or vendors who should be committed to your plans?
- This may take some time, and you may feel you are repeating yourself, but doing this step well will help you not only to get the investment approval, but also during the actual execution phase!
10. Prepare for investment approval
Well, this is it!
- Check schedules for the needed decision making forums and align with your sponsor on DLs!
- Create a clear decision proposal. Prepare the decision making material and ensure prereading material it is ready based on the timelines.
- Prepare the presentation well – and think about potential questions or concerns there may be. If you have done the precooking well, you have practiced your pitch deck already with other audiences.
- People love engaging stories – what is the story behind your proposal? Communicate about WHY this development is critical.
Did you get the approval?
Congratulations, well done! This will be the starting point of your actual execution – a long and interesting journey ahead!
What if you don’t get the approval?
- If there are concreate action points to clarify, this guidance will help you to improve the proposal. Work on the action points and come back with even better proposal.
- What if your initiative will be postponed? This may be very disappointing after all the hard preparation work. However, sometimes there are also other important priorities and your initiative may be more successful when implemented later with proper focus. Collect and document all the lessons learned and organize a proper retrospective with your team – and celebrate all the learnings you have done as a team!
References
[1] https://www.forbes.com/sites/sallypercy/2019/03/13/why-do-change-programs-fail/?sh=428e85e42e48
-
What are the Service Readiness Levels of your new services?

You may be familiar with the Technology Readiness Level (TRL) model originally developed by NASA in the 1970s, today used by many R&D and research organizations. I had wonderful discussions with our R&D and product management colleagues a couple of weeks ago and started to think of how to apply this thinking to new service development, too. After all, it is crucial to understand how ready service concept, commercial model, processes, and organization are for high volume scale-up. Have a look at what I learned about Service Readiness Levels (SRLs)!
Technology Readiness Level for New Product Development
The Technology Readiness Levels (TRLs) defined by NASA [1] have been taken widely into use also in EU-funded Horizon research programs [2]. In the early phases of research on new technology, TRLs 1-3 focus on research of new technology principles, technology concepts and creating a proof of concept – at this point, there is no product. In TRL levels 4-6 technology is further validated in lab environment, validated and later also demonstrated in industrially relevant environments. When moving to TRL 7-9, we start to develop product prototypes, develop a full system scope and have product available in operational environment. Also, sometimes TRL 10 has been identified as a phase, where operations are proven [3].
In practical terms, even when moving forward from TRL 10, there may be different levels of standardization or productization – e.g. is product customized case by case for each customer or is there a standard productized scope with predefined options.
How to evaluate readiness of the service product?
In addition to TRL, also Service Readiness Levels (SRL) have been defined. I found couple of quite interesting sources, while studying the topic [4][5]. I adapted the service readiness levels defined by Whitehouse and Lange [5] to meet my experience in the context of B2B business services:

- SRL 1. Service idea is defined
- SRL 2. High level concept for service defined
- SRL 3. Minimum Viable ‘Service Product’ defined including among others draft value propositions, concept definition, high level processes
- SRL 4. Service is piloted to collect feedback – enabling customer feedback to improve the service product further
- SRL 5. Evidence of service viability is received, e.g. via limited launched for a specific group of customers: are customers willing to pay for service, what feedback do we receive to further improve the service, is the service ‘sellable’?
- SRL 6. Service is Launched for a wider group of customers – this is where the hard work with scaling up starts!
- SRL 7. Organization, processes and supporting tools are optimized to deliver the service – for example optimizing how different supporting IT tools work may require quite some effort!
- SRL 8. Service is rolled out – in large global companies, this may take quite some time to have full global reach!
Typically new service development is highly iterative, and especially in large global companies with regional differences and supply chains, journey from SRL 1 to SRL 8 may take a long time. And in the end, SRL 8 will be the start of continuous development journey to further improve the service based on customer needs and feedback from the organization.
Your organization may have a bit different definitions for service readiness levels, but I think it is a great approach to agree a common way to communicate about service readiness. Using the SRL model, it is possible to map and communicate towards stakeholders of different services in your new service development pipeline. For example visual management via a new service development pipeline may be helpful.
If you have a well managed SRL based pipeline (or still think how to formulate), I would love hear about your experiences!
References
[1] Technology Readiness Levels – NASA Technology Readiness Levels – NASA
[2] EU HORIZON 2020 General annexes – h2020-wp1415-annex-g-trl_en.pdf
[3] Straub, J.: In search of technology readiness level (TRL) 10. In search of technology readiness level (TRL) 10
[4] Gustafson, S.: Service Readiness Levels (SRL)
[5] Whitehouse, D., Lange M.: A Services Readiness Levels Stage Model: A Roadmap, Health Management, Volume 22, Issue 2, 2022.
-
The Quest for Objectivity in Portfolio Management – easier said then done!

One of
Portfolio management should be a neutral party supporting decision making. What I mean here is that when different teams work hard on their important initiatives, they become emotionally attached to the topic – this is human nature for all of us. However, to make smart decisions across the portfolio, the portfolio manager should maintain an objective view across different initiatives and support, coach, and assess all initiatives equally.
However, this is easer said than done – also portfolio management professionals get emotionally attached to both people and initiatives, when helping things to get started and throughout execution. Let’s check out few important viewpoints to consider!
Creating a safe environment to align on different viewpoints

The discussions about large strategic initiatives often becomes difficult due to the diverse viewpoints involved. These differing perspectives can at times be completely opposite, making it challenging to reach a consensus. Here are few tips for creating alignment:
- Sharing draft plans early to collect feedback from different parties – seeing a finalized plan which does not take into account our teams/units needs is frustrating
- Having a neutral party to facilitate difficult alignment discussions – to give enough room for different viewpoints – both sides of the coin
- Building portfolio sharing as a part of portfolio process – people have opportunity to learn about what different teams are working on
Comparing apples and oranges?

Another big challenge for objectivity is the wide range of different types of development ideas and projects included in the same portfolio scope. How to compare objectively process improvement ideas, IT development projects, operational excellence improvements, or new offering development?
- Creating strategic buckets for different types of development to keep portfolio balanced – that is, must have activities related M&A do not eat up the whole budget for the IT development, as both have own buckets.
- Defining a simple portfolio management framework – templates and tools are not always well received, but having is common way to define different initiatives ensures, helps to ensure different aspects are defined and thought through for different initiatives – which often also makes initiatives easier to compare
- Data driven decision making & traditional financial methods, such as calculating the net present value or return of investment may also help. Check out more about prioritization methods from the previous blog.
Corporate politics

In large organizations, when different units have own targets and priorities, there may also be corporate politics. Sometimes the decision making is highly political.
- Understand historical factors driving decision making – this may be especially difficult for new people in the organization, but find people who can help you to understand the background better. Also, if you have been working for a long time in the organization, pause on thinking is the history impacting your thinking and objectivity – usually it is to certain extend, as we are all human beings.
- Help project and program managers to do precooking well – ensure alignment within the organization is reached, before heading to big decision making meetings.
- Ensure portfolio governance forums are functioning – if it is difficult to make the decisions, clarify still governance and decision making forums.
-
Top 4 Tips When Developing Agile Portfolio Management


Has your organization adopted agile methodologies in recent years? Have your portfolio management practices undergone a review as well? If this is relevant for you, I have compiled four tips to assist you.
TIP 1. Start with Agile Principles

First of all, have you had a good discussion related to agile principles, and how they are reflected in your day to day portfolio management practices? This would be a great starting point to see, how your team, portfolio sponsor and key stakeholders consider agile principles are present in your portfolio management, and why not also align on to-be-state – where you would like to be in the future.
Here are few questions to facilitate the discussion:
- Customer value – do you always look into value created to customers (or end-users), when you develop something new or prioritize development? Do you have good examples or cases, where customer value was well considered, or examples where this aspect was forgotten? How could you take customer value stronger into your decision making processes?
- Embracing the change – do you enable changes in the scope of development or do you have a strongly plan driven approach? What happens in practice, if a team identifies a need for scope change after budget approvals? Can agile be systematic and highly disciplined development approach, while still embracing the change?
- Continuous delivery – do you look into outputs and outcomes of development frequently? How do see the progress in practice, for example via demos, reviews or sharing sessions? Is your development methodology supporting continuous delivery approach or do you have gigantic development programs with big bang approach?
- Collaboration – do you encourage collaboration across the organizational units? Is collaboration, sharing and alignment inbuilt into your portfolio management routines and processes?
- Self organizing teams – do teams have needed end-to-end knowledge to work independently? Are teams empowered to do needed decisions based on the clear guardrails? How could you help teams with smooth portfolio level decision making?
- Simplicity – Is your goal to maximizing the work not done? What is the guidance when you plan or projectize development work – do you try to include comprehensively all scope into the project plan, or do you focus on development first Minimum Viable Product? How do you approach prioritization in the portfolio level?
Many times agile way of working has been growing organically within the organization, and portfolio management has not been the focus area during the transition. If this is the case within your organization, it is good to see where you are today already strong, and which principles should be strengthened in the context of portfolio management. Also, as all organizations are unique, you may choose some of the principles as your guiding principles and focus areas to first develop in the context of development portfolio management.
TIP 2. Review development portfolio roles

Often when moving towards agile ways of working, also portfolio roles may be impacted significantly. If the use of agile practices has become popular within the organization, it may be a good time to review and discuss the portfolio management roles, too. Here are few roles to start review with:
- If development is carried out more and more via agile teams, has the project and program manager roles been adapted? When developing something complex, something completely new, who looks into the big picture to ensure the smooth and timely flow of development across different teams?
- How about the portfolio manager role – is portfolio manager looking into the traditional project portfolio, or covering also the development happening via the agile development teams? Are there new areas to learn for your portfolio management team in the context of agile?
- Are business owners actively participating to agile development prioritisation, reviews and demos? And do you have product owner role standardized? If you initiate a new team, is it clear what is expected from a product owner in your organization? How about end-to-end process view, is it covered by certain roles?
- Do you have new roles introduced, such as agile coaches, scrum masters, release train engineers? How do you collaborate with these different roles for development portfolio viewpoint?
Many times, when agile is not scaled across the organization, there may be a mix of different roles within different units even with the same development portfolio area. And in this case, it is important to identify the different roles, and also agree how you work together when it comes to portfolio related topics, such as planning and decision making.
TIP 3. Visualize Development Portfolio

A good approach for any development portfolio every now and then is to look into the content of the portfolio – what is actually included in there? This is especially good activity, if you have not done it lately.
- You can just take a big whiteboard and sketch the structure with your colleagues! If you visual your portfolio, what does it look like? Do you have a strong project portfolio? Do you have large development programs? Do you have value streams? Anything else?
- If you have a portfolio management tool – is agile development covered in the tool, portfolio plans and reporting?
- Follow the money – where is the development budget spend? Do you have large budget lines, which are not really visible in the portfolio level?
- Portfolio Kanban is also a great tool, especially if you want to visualize your portfolio funnel, a dedicated blog post focusing on this topic here: Do you manage a Portfolio funnel, or Portfolio tunnel?
Sometimes, development happening via the agile teams is almost invisible in the development portfolio scope – this may very well be the case, if the organisation is looking into the traditional project portfolio management. If this is the case for you too, you might find this blog post helpful: From project portfolios to hybrid portfolios – combining projects and agile work
TIP 4. Review Agile Portfolio Management Practices

If you have state of art project portfolio management practices in place, how do you take into account agile development? Here are some of my favorite practices to get you inspired:
- Portfolio governance – do you have a project gate driven portfolio process? If your portfolio has more and more agile development portfolio review driven approach may work better. Have a look at tips here: Time for A Quarterly Portfolio Review?
- Do you have a clear and engaging future vision? Finding Your North Star – Creating a Shared Long Term Vision – have a look for inspiration?
- Do you have a challenge with closing the gap between strategy and development? Closing the gap between strategy and development portfolios using Objectives and Key Results (OKRs) is a great tool to solve this challenge!
I hope you got some inspiration for developing agile portfolio management approach in your organization. And as always, I would be happy to learn what works for you, and where you might be facing challenges – so let’s connect!
Interested to learn more? Have a look:
- Agile manifesto
- From project portfolios to hybrid portfolios – combining projects and agile work
- Do you manage a Portfolio funnel, or Portfolio tunnel?
- Time for A Quarterly Portfolio Review?
- Closing the gap between strategy and development portfolios using Objectives and Key Results (OKRs)
- Finding Your North Star – Creating a Shared Long Term Vision
-
How is your development portfolio impacting future run costs? Portfolio finances, part II

When we are developing something new, we often look into development costs and benefits received from the development. What is often forgotten, is the impact of development initiatives to organizational run costs. If we develop a new automated process with new tools, we might need to hire also new people to maintain the solution, as well as have license costs. And sometimes the growth of the costs is also a very positive topic. Let’s review this aspect for a moment!
Forecasting impact of development – including both benefits and run costs

When we develop something new, we often focus on development costs – how much Opex or Capex investment is, how much internal work related costs. However, development has often significant impacts on future profits and also operating costs.
If you have fore example rolling 5 forecasting or LRP process ongoing, here are the key high level topics to consider:
- Opex impact – When your development project is ending, will there be some new license costs or increased IT capacity costs to be covered? Which department is budgeting these costs, and have the costs been reviewed and agreed with that department to avoid issues with future budgets?
- Headcount impact – When the project ends, do we need to have additional headcount managing the run phase of the solutions? Has the headcount needs been analyzed together with the business case and impacted department agreed on headcount plans?
- Capex impact – If you have Capex plan, is the original capex plan still valid, or has there been any changes in the development schedules or development cost forecast, which might also impact the capex plan?
Typically at the early phases of development, is is really difficult to know the run phase costs, and business case may not be so accurate. However, when the development project is proceeding, it is a good practice to review the business case and also take the future costs into the forecasting processes.
Increasing run costs – what is the total cost of ownership?

Let’s look into Increasing run costs first. When automating something, we typically get plenty of benefits from saving time, and for that part, there is often detailed benefit calculations in place to justify the business case. Even the development phase costs are often analyzed in detail, to enable investment decision making.
However, what is often forgotten is the run costs after the development phase. Here are few topics, which I have been looking into
- What is the licensing model in place for your solution? Is the license costs depending the amount of total users, do you have floating licenses with maximum amount of users at the same time, or do you have yearly or monthly license fee, and you can use the solution as much as you wish. Depending on the licensing model, it is important to evaluate the future usage, when developing the business case.
- What is cost of keep the business running? If you would not do any development, what would be the cost of keeping the solution running after the go-live? Do you have costs related to physical servers or cloud capacity, or within connectivity infrastructure?
- What are the continuous development costs? In addition to keep the business running, there is typically an expectation of continuous development of the newly built solution. Are you budgeting also money or and resources for this important work?
If you have long range planning period starting, check out also the previous blog post: 5 Tips for Smoother Long Range Planning for Development Portfolios – Strategic Portfolio Management!
Let’s cover the headcount impact next, that is relevant too!
Impact on headcount and internal work

I think this is a really tricky topic!
If we develop a new product or service or a new IT solution – there is a need to run and continuously develop the solution further.
- Who will take the ownership of the development outcome? Is there a team, or would you need to build a new team requiring internal headcount or external team members covered via Opex costs?
- Will the new product or solution require support from many different units or team? Can the increased work be managed within the existing resourcing, or will there be headcount needs in multiple teams?
- And perhaps the most difficult part! Do you have the needed capabilities, skills and knowledge in the organization, and would you need to create a plan for hiring new people, and what would be the location for these people?
New revenue streams – creating organic growth of run costs?

Sometimes the growth of the costs is a positive thing!
This is the case when the growth of the digital service volumes is increasing the business revenues and profitability, but on the other hand also increasing organically service run costs, license costs, connectivity or data costs or other service management costs.
It is good to take this into account already when reviewing the business case. Here are few topics to consider:
- What is the best forecast for the service volume increase, and what is the impact on the run costs? Do you have multiple scenarios, such as optimistic, neutral and pessimistic scenario?
- Which unit or organization is budgeting the future increase in run costs?
- Are these costs allocated in your processes to the units receiving also the profits? Do you have processes in place for allocating the costs, or do you need develop your ‘digital supply chain’ practices further?
- How do you govern and follow up these costs?
- How do you optimize the cost structure also in the future to optimize service profitability?
Recommended reading
5 Tips for Smoother Long Range Planning for Development Portfolios – Strategic Portfolio Management
-
Creating portfolio transparency – how to create meaningful portfolio structures?

Communicating about development portfolios is often tricky – there may be a lot of ongoing development projects and activities, and if there are no portfolio structures, such as programs grouping projects, it is difficult to present high-level portfolio updates. The last blog post was focusing on designing portfolios in Enterprise level – let’s now focus on a single portfolio design and meaningful portfolio structures.
Here are a few tips which have been helpful for me and my colleagues!
Portfolio level – Large single portfolio, or multiple portfolios?

By definition A portfolio is a collection of projects, programs, subsidiary portfolios, and operations managed as a group to achieve strategic objectives (The standard for portfolio management – Project Management Institute, 2017). The definition is quite wide and each portfolio needs to define how to structure the development happening within the portfolio with a meaningful value adding way.
Sometimes portfolios may develop content across businesses, but also quite often there are own development portfolios for different businesses and functions. In addition to business-driven portfolios, often large development organizations, such as R&D and IT, also have their own portfolios. These portfolios may have own strategic targets, or work may be delivered to one of the business portfolios by the technology units. Also global functions, such as marketing or finance, often have their own development portfolios. First thing to consider is, do you manage a single portfolio, or would you have actually multiple portfolios with different objectives in the scope of discussions.
Sometimes there are clearly defined project portfolios, a group of individual projects, without any need for program structures – and this is completely fine, too. When dealing with larger portfolios, it makes sense to manage group development activities as sub-portfolios, programs, strategic initiatives, or via value streams. Let’s review different options:
Sub Portfolio – Grouping of development based on unit, department or theme

Let’s start with sub portfolios!
For large development portfolios, sub portfolio structures truly make sense – there is just too much different types of contents to be managed with flat hierarchy. On the other hand, for smaller portfolios, splitting content too much may create additional bureaucracy and silos within organization – so please be careful with the design!
Here are couple of tips for large portfolios with different types of development contents:
- Sub portfolios for different units: Do you have have a big development portfolio developing content for different units? For example, if your portfolio is focusing on development within global functions, development content within marketing, finance and IT would deserve to have own sub portfolios to keep the content well grouped and managed.
- Department level sub portfolios: For big business portfolios, does it make sense, to create a sub portfolios for development work different departments are focusing? Sub portfolios may help to create structure and show logically development projects focusing on development of each area. Sub portfolios may also serve well for allocation of funding and governance, if decision makers and key stakeholders vary a lot. Also, one very important aspect is the resourcing – each department needs to have a clear view of all development they need to resource.
- Strategic theme based sub portfolios: Do you have big investment areas including multiple interlinked programs you need to present together? Sometimes sub portfolio may be also created based on the strategic development themes, to be able to easier follow up on
Development Programs – managing complex dependencies

Development programs are widely implemented across various industries as a common and well-known approach. The fundamental concept behind programs is to consolidate interconnected projects with shared objectives into a unified program, which can be managed as an entity. One particularly appealing aspect of development programs is the incremental delivery of benefits, as individual projects or activities within the program are completed over its duration.
Sometimes projects and other development activities within program have complex dependencies – and the completion of one activity may be a prerequisite for another. One of the benefits with program structure is the possibility to manage dependencies systematically – this is especially important, if development is happening across different organizational units.
Some programs may have more loosely interlinked projects based on a certain theme or topic – this could be for example projects linking to the same technology. Also the investment decision approach may vary – if each project within the program has an own business case, investment decisions can be made also incrementally over time – this helps to get things started, when in the early phase investment approval is only for the first scope items.
Strategic Initiatives – aiming at reaching strategic targets

Strategic development portfolios often encompass strategic initiatives, such as large transformation projects, strategic technology programs, must-win battles, or major product development initiatives. These initiatives are typically characterized by a strong focus on outcomes, aiming to develop new offerings, introduce new business models, or enhance organizational capabilities.
Sometimes strategic initiatives are governed as an entity, with a clear funding, steering and reporting practices, but often there is more loose practice, mainly focusing on strategy implementation progress – development is happening within each responsible organization. What ever the structure you may have, creating transparency on strategy implementation progress is usually a must have need!
Value streams

Today, value streams developing end-to-end chains delivering customer value have become popular, especially when enterprise agile practices are widely used in the organization.
Some portfolios are fully organized around value streams, and in a sense, value streams may be seen as mini-portfolios. There is typically a higher level decision-making on the portfolio level, but also teams working within value streams are empowered to make decisions about content prioritization. If you want to learn more about portfolio approach using value streams, Scaled Agile Framework Portfolio pages include great examples.
Smart portfolio views – other portfolio grouping attributes

In addition to official portfolio structures, such as Sub portfolios or Programs, there are often also other needs to create views of development portfolio content. Optimally, your portfolio management tool may help with this, to avoid maintaining roadmaps for different purposes.
These are the commonly needed views I have come across to:
- Department or unit work view across development portfolios – what are the projects and other work ongoing with your own unit? Which projects are you leading, where are you contributing and your team member contribution is needed? This view is especially important for common functions, such as IT departments or marketing, where there is always high demand for your experts time, and need may be coming from many different portfolios.
- Strategy view – which development initiatives across all portfolios are contributing to a strategic theme or must win battle? There is often strategy progress reporting also consolidating status from different units, and great approach is to link strategy reporting to development portfolio reporting to avoid double reporting.
- Product line, Platform or Solution area roadmap view – also a typical need is search for all development initiatives linked to a certain Product line, Platform or Solution area. With this view it is possible to manage development dependencies for a certain area.
Backlogs and my own tasks…

The need for managing the work does not end to portfolio level. Development teams have needs to manage their own roadmaps, backlogs or Kanbans – and the same applies to all of us – we need to manage our own tasks systematically. We all hate, if we need to create additional documentation manually to report our progress – and here is an opportunity to use integrated portfolio and backlog management tools.
If you have possibility to use the same set of tools within company – managing work from different projects or areas may become easier for the individual, when all tasks can be found from the same tool. The same applies also for the portfolio level – especially for agile development, creating transparency on progress of roadmap items is crucial. Many portfolio management tools today enable integration or have great inbuilt functionalities for managing backlogs.
If you are interested to learn more, check these out:
The standard for portfolio management – Project Management Institute, 2017
Development portfolios in large companies – what is your viewpoint?
Designing Development Portfolios in Enterprise Level – What is your approach?
