• What is the correct level of productisation?

    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:

    1. What volume levels are you targeting with this product?
    2. What level of flexibility are your customers expecting in terms of offering options?
    3. How much time, effort, and money are you willing to invest to productise the solution?
    4. What is the correct time to invest in productisation work in your case?
    5. Do you have good documentation in different areas to support the rest of the organization (technical, commercial, process documentation)?
    6. 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!

    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:

    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?

    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!

    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

    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:

    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:

    1. Agile manifesto
    2. From project portfolios to hybrid portfolios – combining projects and agile work
    3. Do you manage a Portfolio funnel, or Portfolio tunnel?
    4. Time for A Quarterly Portfolio Review?
    5. Closing the gap between strategy and development portfolios using Objectives and Key Results (OKRs)
    6. Finding Your North Star – Creating a Shared Long Term Vision

  • How is your development portfolio impacting future run costs? Portfolio finances, part II

    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

    From Managing Past Costs to Rolling Forecasting – Development Portfolio Finances (part I) – Strategic Portfolio Management

    5 Tips for Smoother Long Range Planning for Development Portfolios – Strategic Portfolio Management

  • Creating portfolio transparency – how to create meaningful portfolio structures?

    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?

    Scaled Agile Framework Portfolio pages

    , ,

  • Designing Development Portfolios in Enterprise Level – What is your approach?

    Designing Development Portfolios in Enterprise Level – What is your approach?

    New business strategy, big organizational or operating model change, or merge of companies may lead to a need to redesign the development portfolio structure. Also, the introduction of Lean and Agile ways of working may impact portfolio design. Let’s check out different options for Enterprise level designs, and also some key topics to consider when planning the setup:

    Portfolio structure based on business units and functions

    A common way to get organized around development portfolios is to organize development into development portfolios owned by different business units and functions. This has been also a traditional ways within project portfolios – different units manage their own development portfolios taking business unit strategy into action. With large businesses, portfolios may be also slit to sub portfolios owned and managed by different departments, as the development content may vary a lot. Within business portfolios, development may be organized around projects, Programs, strategic initiatives, such as Must win battles.

    Also global functions, such as HR and Finance often have own development portfolios, developing cross business capabilities. When the development is organized based on the ownership of work, also R&D and IT have their own development portfolios.

    The model where development is organized around units works well, when each unit have clear roles and responsibilities in the strategy implementation, and development content does not typically requiring work from many other units.

    Key points to consider in the enterprise portfolio level: is development happening across different unit portfolios aligned to take the strategy action optimally? Is there enterprise level transparency on key initiatives? How do you follow up on strategy implementation?

    Let’s check out also other ways to get organized!

    Cross organization transformation programs

    When developing content which requires contribution from many different units and teams, there is no single clear owner in the organization and development outcomes impact the whole company, a common approach is to get organized around cross organizational transformation programs. Typical examples of such implementations may be for example ERP or CRM implementations impacting business processes, operating model and IT solutions for many different units.

    Setting up governance, resourcing and way of working for such transformation programs require a lot of alignment – how are each unit contributing with the resourcing, who makes the decisions, who has the budgets? Do you have an enterprise level portfolio for these strategic transformations, or is one of global organizations owning the initiatives?

    Key points to consider in the enterprise portfolio level: are several large transformative initiatives ongoing at the same time, and could the initiatives be sequences to ensure success of critical ones? How do you manage the governance to make transformation successful?

    Value stream based portfolio structure

    Today more and more development is organized via agile development. I happed to check out Scaled Agile Framework 6.0 last weekend, and there was a really nice Portfolio site added to the framework: Portfolio – Scaled Agile Framework. In the Scaled Agile Portfolios, development is organized around Development Value streams, and portfolios are organized around value. I like the thinking, to optimize the flow – however, this is a big change in thinking from the traditional way of organizing development into unit or function development portfolios. There are great examples, among others of business unit, regional or innovation portfolios within the sites, so check it out, if this is useful for you.

    Key points to consider in the enterprise portfolio level: how is agile development visible in your development portfolios? Are you organized around value or around functions?

    Optimizing the use of capacity

    One of the key challenges for many professional development organizations, such as IT teams and R&D is how to optimize the use of capacity. Especially in the models, where IT development is distributed in many different business unit organizations, there may hundreds of projects ongoing with different types or resourcing needs from the same teams – and the there are typically few experts who’s contribution would be needed in many projects at the same time. How can a resource manager make the decision which initiative should get the results? Is it based on who shouts loudest?

    Key points to consider in the enterprise portfolio level: how do you create transparency and prioritize work from different portfolios? Do you have too many smileys in the pipeline, considering the expert resources you have?

    Managing cross portfolio dependencies

    When development is happening in multiple development portfolios simultaneously, there is a danger of developing simultaneously similar solutions without alignment – leading to waste. There may be also complex dependencies between different initiatives, via common enablers, shared technical components or key resources. Creating transparency and alignment may require sharing sessions, discussions and sometimes also common portfolio management tools may also help.

    Also enterprise architecture team plays a key role here – when the development is becoming more and more complex, someone needs to look into the solutions at the company level – to find synergies, to use common building blocks, and to avoid sub optimal solutions.

    What does enterprise architecture have to do with enterprise level portfolios? Well, today, when development content has become increasingly complex,

    Key points to consider in the enterprise portfolio level: Are development portfolio dependencies managed actively to see synergies between different initiatives? Is enterprise architecture team looking across all development portfolios to ensure smart decisions for the whole organization are made when developing IT and digital solutions?

    Recommended reading

    Portfolio – Scaled Agile Framework

    You might be also interested in one of the previous blogs:

    Development Portfolios In Large Companies – What Is Your Viewpoint?

    Finding The Balance – Centralized vs. Decentralized Portfolio Management

    Strategic Portfolio Management, part I

  • Managing offering portfolio – boosting existing offering or develop new offering – or both?

    Managing offering portfolio – boosting existing offering or develop new offering – or both?

    I have had great discussions with peers in different companies related to service offering portfolios, and I have noticed there are truly many viewpoints to offering portfolios.

    Teams focusing on development usually think more about the New Offering Development Portfolio – what are the new offering development initiatives teams are focusing on? Also there are brilliant development ideas from many different sources in the Idea pipeline to develop new service concepts or to further improve current offering with new features. When discussing with the sales and operations people, focus is naturally on available customer offering portfolio: what can we sell for different customers segments and in different geographical areas? How do we bundle offering – what to sell together?

    Here is how I have structured this portfolio funnel based on the literature, but also based on practical experience:

    Service Idea Pipeline

    Service innovation space was already covered in detail in the previous blog post: Exploring Service Innovation Space.

    Based on the studies, the ideas for new service offerings may be originated form many different sources: from customer co-creation and feedbacks, from the sales teams actively meeting the customers, from the operations delivering the service, or any other internal stakeholder groups, partners or even from regulation or legislation. To capture systematically these ideas is critical – otherwise your next 1 billion opportunity may be lost.

    Capturing the idea into innovation tool or backlog is not enough – the idea requires analysis – do we have be business case, is the idea aligned with the strategy, and how the idea could potentially be implemented? Here are few good practices, which are

    • Collect actively development ideas from many different sources: customers, partners, service delivery organization and operations, sales, R&D and other stakeholder groups.
    • Consider both incremental development ideas of existing services, but also new innovative ideas which could lead to new service concepts within your organization.
    • Create a funnel for development ideas to see in which phase idea is – this is really important to manage the expectations – you don’t one anyone to start to sell something, when idea is still just an idea.
    • Be willing to kill your darlings – one easily falls in love with the idea team has worked hard on – however, if you cannot find business case or strategy fit – idea should be killed or parked to be consider in the future.

    New Service Development Portfolio

    Within New Service Development Portfolio, we should see all service development initiatives, which are under development. There may be large development initiatives, such as development programs requiring work from many different teams and units, but also smaller incremental development activities to improve the existing services.

    Good practices:

    • Create transparency on service development activities. Projectize the service development, as you would do for new product development. In many organizations, service development is incremental and not fully visible in development portfolios. Projectized approach helps to create transparency within the organization on status and readiness of service development. If you develop services via continuous development teams, that is equally ok – create transparency via portfolio epics or other means.
    • Also services require systematical productization and commercialization – in order to develop a scalable service, one needs to carefully understand customer value proposition, define the processes and way of working for the service, train the organization, and often also develop supporting IT tooling. Usually this is more work than anyone anticipated, when kick starting the project!
    • New Service Development differs from the New product development – fine tune your service development process to enable iterative learning, customer engagement and flexibility in decision making. Read more here: Developing new products and services – are there differences?
    • Don’t forget deployment – when you have invested so much on service development, make sure you pay enough attention on engaging the whole organization, so that the sales is capable to sell new services, delivery organizations knows how to manage delivery and commissioning and operations have smooth processes for running the services. Create feedback loops to improve the services based on the learnings!
    • Check out also tips for go-to-market: 5 ways to improve go-to-market of new offering.

    Customer offering portfolio

    In customer offering portfolio, we may have a wide range of available offerings towards customers, depending on the size of your portfolio.

    Here are few topics to consider for the existing offering portfolio:

    • Creating clarity towards customers and sales on available offering is critical. There are many ways for creating the transparency, and sometimes also multiple viewpoints may be need. Read more of offering portfolio dimensions in a previous blog post: Ideas To Build Offering Portfolio – Which Offering Portfolio Dimensions Are Relevant For Your Organization?
    • Do you have offerings you are still scaling up within the organization? Systematic post-launch follow up is absolutely critical. And not only to passively follow up, but gather feedback from customers, own organization, partners and competition to truly optimize your results.
    • Can you create transparency on performance of the offering portfolio? Do you get easily numbers, or would you need to take some actions to improve the performance management across all offerings?
    • Do you have retiring offerings in your portfolio? Make also bold decisions to retire offerings, which are not performing as expected or are replaced by a new offering. Maintaining too many services simultaneously requires a lot from the whole organization.

    Do you manage a funnel or a tunnel?

    One of my most read blog posts has been about managing the portfolio funnel (Do you manage a Portfolio funnel, or Portfolio tunnel?). The same principles apply to the service offering portfolio as for any other portfolio – it is important to look into the different phases of the portfolio funnel, prioritize and create transparency, and not to just focus on one specific part. For me this illustration has helped a lot when we have had a confusion offerings in different phases of the funnel:

    As always, I hope this helps! And happy to hear your reflections, both if you agree or disagree on certain parts!

  • Exploring Service Innovation Space – Are you utilizing all opportunities?

    Exploring Service Innovation Space – Are you utilizing all opportunities?

    Thank you to the network for the engaging discussions centered on service innovation and ideation over the past months. I have been looking deeper into the service innovation space, and I’ve come across some valuable insights from researchers to give food for thought!

    What is service innovation?

    The service innovation space refers to the activities related to developing and improving services. It involves applying innovative strategies, technologies, and processes to enhance the value, efficiency, and customer experience of service-based businesses.

    Service innovation can take many forms and can be applied across a wide range of sectors, including finance, healthcare, retail, transportation, hospitality, and more. The aim is to create new or improved services that meet the evolving needs and expectations of customers while also create business growth and competitiveness.

    In the service innovation space, organizations often adopt a customer-centric approach, putting the customer at the center of their innovation efforts. This involves understanding customer preferences, pain points, and aspirations to identify opportunities for service improvement and differentiation. Service innovation unfolds through multifaceted approaches:

    • Co-creation: Involving customers and other stakeholders in the service design process to ensure that the final product meets their needs and desires.
    • Digital transformation: Leveraging digital technologies such as Internet of Things, artificial intelligence, data analytics, automation, and mobile applications to enhance service delivery, personalization, and efficiency.
    • Optimizing processes: Streamlining and improving internal processes to reduce costs, increase productivity, and deliver services more efficiently.
    • Developing a Service ecosystem: Collaborating with partners and integrating complementary services to create a comprehensive ecosystem that delivers enhanced value to customers.
    • Service management: Implementing processes to effectively address service failures or customer dissatisfaction, and turning negative experiences into positive ones and building customer loyalty.
    • Continuous improvement: Establishing systematic way of working for feedback collection, analysis, and learning to identify areas for service enhancement and maintain a culture of innovation.

    Food for thought: Do you you leverage all of these areas already now? Or would you have opportunities for example via improved service management, being more systematic with the continuous improvement feedback loops, or building the partnerships?

    Framework for Service innovation space

    Service innovation may take many forms, and I really liked the framework proposed by Bessant and Davies (2007) including four types of service innovations:

    • Service offering innovation – changes in the actual offering or value proposition
    • Process innovation – changes how services are created and delivered
    • Position innovation – changes in the context of the service
    • Paradigm innovation – a holistic change in the mental models underlying the business

    Another aspect highlighted in the model by Bessant and Davies, was that the innovations can be radical or incremental – for each ‘innovation type’. If you are interested to learn more, check out the excellent article with examples included, too.

    Food for thought: If you think about the innovative services from your organization context – to which category would do they belong to? Would you have opportunities to explore also other categories more? Furthermore, do have radical innovations or incremental innovations in your portfolio?

    Service innovation activities

    Another great article I would recommend is Daniel Kindström: Towards a service-based business model – Key aspects for future competitive advantage! Have a look at the article, but I will shortly share my key takeaways related to Service innovation activities here:

    1. Value proposition – starting from the customer value propositions and validating how is the innovative new service creating customer value.
    2. Revenue mechanisms – moving from cost plus pricing to value based pricing and finding the best pricing model fitting customer needs; finding advanced revenue schemes via partnerships.
    3. Value chain – developing the value chain from easy to address value parameters for sales, designing service development process and supporting organizational roles.
    4. Value network – identifying the opportunities to expand value proposition via the value network, involving both customers, partners and suppliers to enable best service delivery; taking the coordination role within the value network
    5. Competitive strategy and target market – developing service strategy for differentiation, and identifying target customer segments, and customer roles based on the value created.

    Food for thought: Are these service innovation activities inbuilt into your service development processes, or would benefit taking a closer look into some of these items? I would consider all of these aspects critical, when working with new innovative service concepts.

    The service innovation space is constantly evolving, driven by changing customer expectations, technological advancements, and competitive pressures. Organizations that embrace service innovation and adapt to the evolving landscape are better positioned to succeed creating differentiation from the competition. For me, developing services is balancing between continuous improvement of existing services, but also developing new innovative service concepts!

    I hope you got some inspiration from the blog, and let’s exchange thoughts, if the topic is close to your heart!

    References

    Bessant, J. and Davies, A. (2007) Managing service innovation. Innovation in Services (DTI Occasional Paper No. 9). Department of Trade and Industry, UK.

    Daniel Kindström: Towards a service-based business model – Key aspects for future competitive advantage European Management Journal (2010) 28, 479– 490)

Leave a comment