Project work and developing new products and solutions require a lot from the teams – there may be complex problems to be solved, challenges to get started with the new initiative, stretched timelines to meet, and different types of needs coming from many different stakeholder groups. But even though development work is often very demanding – the best teams still manage to have fun together and achieve a lot!
I am part of my workplace Grow training this autumn and got inspired by the psychological safety theme – here are some reflections on how psychological safety can help Development portfolios perform better!
Making things happen – and having fun in the team level
I am a big fun of Amy Edmondson – and her Creating a Fearless Organization. Based on Amy Edmondson, Psychological safety is not about being nice, avoiding conflicts or an excuse to complain, but creating an environment where development teams have high performance standards, but still feeling safe enough to speak up about mistakes and concerns – and being unafraid to bring up also ideas and questions.
Based on my experience, best performing teams make things happen, but also still manage to have fun. For me, it is always a good sign, when I hear laughter from the development team. When the team has fun together, is also easier to bring up difficult topics, and also find the solutions. Best teams have also fierce debates, as the aim is to find the best solutions. And not to forget wild ideas, which can be enhanced and enriched together as a team.
Inviting to participation – across the organization
When developing complex solutions impacting the work of different business units and end-to-end processes, a significant amount of communication and alignment across the organization is needed. Does the development team feel safe when introducing new ideas and concepts with the stakeholders? How is the feedback given and received?
As a lead of a strategic initiative, there may be many stakeholders groups to be alignment with – and a need to build new connections between the units, which have not been earlier collaborating actively. The way of working, terminology and tools used may differ, and there is a big risk of misunderstanding. Here it is important to keep the big picture, but also actively align with different stakeholder groups, listen and use the feedbacks actively to improve the final outcomes. Are your workshops safe environment to give feedback, bring up ideas and debate?
As a stakeholder of a strategic initiative, it is important to offer support for the development team, even though topic might be new to you, and you may feel uncomfortable to certain extend. Listening actively, and trying to connect the development vision to your own area of expertise is important – and to avoid starting with your own agenda first. Also, bringing up the potential development needs is important, as the development team may not have all the needed knowledge for end-to-end value chain. Are you giving the feedback in a constructive way, which are easy to take into considerationand invite to dive deeper into the topic together?
One of the clear trends I have seen in many companies, is to reduce the amount of steering meetings, and increase the amount of sharing via other means. Great practice widely used by agile teams is to organize demos and reviews – seeing concretely what has been developed helps everyone to understand the content, and bring up also development needs.
Psychological safety in portfolio level decision making
When I was quite fresh from the university, I was working for a large transformation program which had been ongoing for several years. The planned go-live was closing and many team members were really worried about the performance of the solution – as after go-live, the new system could risk the company continuity. When the performance issues were discussed, an experienced management consultant gave an advice: “Senior managers are like sheep, you don’t want to scare them off.”
Well, after all these years I still disagree with that – teams should feel comfortable bringing up also concerns and senior management deserves to get objective and data based understanding. In the end for that specific project, company internal controls worked as they should, and the performance challenges were addressed before the go-live. Oh, what a learning it was for all the stakeholders involved, and big emotions also involved!
Another big ERP implementation project, where I worked, faced a big challenge with technical environments one month prior to go-live. As a program lead, this was not an easy news to bring up, but as a team, we got the full support from the management and all the vendors involved, and the year end schedule was kept thanks to good team work. I think here psychological safety played a key role in that case – discussing openly about the challenge enabled also finding the solutions with all parties.
Here are few tips for portfolio managers and senior management to help the teams:
Encourage teams to share, organize demos and reviews with the rest of the organization – this helps to create alignment and get feedbacks early. Seeing is believing! Participate, sponsor and create a positive and encouraging atmosphere to these events!
No news is not always good news – encourage teams to share openly about their progress and seek for alignment – not only within gate approvals, then it might be too late.
Build flexibility into the decision making – can teams bring up key topics to decision making forum to inform senior management or when guidance is needed?
Don’t kill the messenger – when something goes wrong, don’t find who to blame, but think ways to support to solve the challenge!
Hearing laughter during team meetings is usually a good sign – the best teams have fun and also achieve a lot together!
Today, the complexity of solutions, processes and IT tools has grown, and development teams are working with complex challenges.
Based on the great discussions on the previous blog posts related to agile teams and business agility, here is another post related agile teams. The concept of a “team of teams” was popularized by General Stanley McChrystal in his book “Team of Teams: New Rules of Engagement for a Complex World.” Here are some key ideas related to the concept, to give inspiration:
Dealing with complexity and rapidly changing environment by distributing decision-making authority
Traditional hierarchical structures and command-and-control systems are often inadequate in dealing withcomplex and rapidly changing environments. In today’s interconnected world, challenges are typically complex and require flexible and adaptive approaches. To effectively tackle complex challenges, organizations need to move away from centralized decision-making and embrace a more decentralized approach. Decision-making authority should be distributed to the teams on the ground who have the most relevant information and expertise.
Each team within the organization should be empowered to make decisions and take action based on their understanding of the mission and the information available to them. This requires trust, clear communication, and a shared understanding of the organization’s priorities and values. In the portfolio level, clear guiderails may help to achieve this – what decisions can be made in the team level, and where portfolio level decision making is needed?
Transparency and shared consciousness
Another key idea from the book, is that establishing a shared consciousness across the organization is important. This means that all teams should have access to real-time information and a common understanding of the larger mission and goals. Open communication and transparency are essential for creating this shared consciousness.
Rather than operating in isolated silos, teams should form collaborative networks that allow for effective coordination and information sharing. Inter-team collaboration and cross-functional communication are vital for breaking down organizational barriers and enabling collective problem-solving.
Is the current way of getting organized around development support collaboration?
Experimentation and continuous learning
The team of teams approach emphasizes the importance of continuous learning and adaptation. Teams should be encouraged to experiment, learn from failures, and iterate on their approaches. A culture of learning and innovation is necessary for staying agile in a rapidly changing environment.
Traditionally waterfall based state-gate models have not supported the experimentation and iterative learning – how is it today in your organization?
The new role of the leader
Traditional leadership roles also need to adapt to the team of teams model. Leaders should focus on providing guidance, fostering collaboration, and creating an environment where teams can thrive. The role of leaders is to empower and enable teams rather than micromanage or control them.
Overall, the team of teams concept promotes a more agile, decentralized, and collaborative approach to tackling complex challenges. By leveraging the collective intelligence and capabilities of teams, organizations can become more responsive, adaptable, and effective in today’s dynamic world. If interested to learn more, I would recommend checking out this book!
References
McChrystal S., Collins T., Silverman D. & Fussel C. 2015. Team of teams. New rules of engagement for a complex world. Portfolio Penguin.
Today more and more development is carried out via agile teams. When discussing with colleagues from different companies, the terminology and the ways of working seem to vary a lot across companies and even within one organization. This is not surprising, as there is no one and only way for agile – agile mindset, values and principles may be implemented using a large variety of practices and methodologies.
Agile manifesto was published 2001, defining 4 core values and 12 principles. These values and principles should be share across agile teams, but there is a huge amount of practices and also many agile methods used among the practitioners. Some companies have implemented enterprise agile, based on SAFe or LeSS frameworks, but in many organizations agile has grown organically, and each team has optimized the ways of working and applied agile practices to best fit their unique needs.
When discussing with peers, I have come up with at least the following terminology related to agile teams: agile team, continuous development or continuous improvement team, Scrum team, Kanban team, DevOps team, product team, and task force. Then there may be value streams, ARTs, teams of teams, or tribes. A beloved child has many names – what do you call your agile teams?
I will try to consolidate some of my favorite content and links here related to agile teams, as this is an area, I want to learn more, too! If you have great content related tips, please ping me!
How is team defined in Agile?
So how is team defined in Agile? Let’s have a look!
A “team” in the Agile sense is a small group of people, assigned to the same project or effort, nearly all of them on a full-time basis. … The notion of team entails shared accountability: good or bad, the outcomes should be attributed to the entire team rather than to any individual. The team is expected to possess all of the necessary competencies, whether technical or business.
The definition provided is quite wide, and there are many great ways to work with agile methods. Even though methodologies and approaches from team to team seem to differ a lot, there are certain common characteristics across different teams. Here are a few which I have noticed are quite common:
Developing something new – as all teams are unique, it may be new beautiful product features, a use case in a sales tool enabling a new business model, enhancement of ERP system for better efficiency, or a change in the business process
Regular releases or delivery of new content – the release cycles differ a lot from team to team from daily releases to quarterly releases
The team works together, learns together, and achieves together – there may have company internal and external team members, and there is continuity in the team. If one member of the team leaves, the team has the competences to bring in a new team member quickly.
There is regular prioritization of the content together with the key stakeholders. Prioritization may happen bi-weekly, monthly, or quarterly, this seems to depend a lot on the team and content the team is developing. Sometimes there is clear product ownership presenting also the voice of different stakeholders and customers, sometimes there are multiple stakeholders.
The team is managing the work via a backlog or for example Kanban board. For the portfolio level, the higher-level roadmap is a great tool to communicate the team plans with a wider group of people. Sometimes there is a detailed roadmap for the next quarter and high level epics or themes for the 1-3 years.
Many teams utilize a mix of Agile methods, such as using Scrum or Kanban. So let’s have a look at these, too!
Agile methods – Scrum, Kanban, XP, Lean…
Agile methodologies are a set of principles and practices that enable teams to deliver high-quality products or services in a flexible, iterative or incremental manner. These methodologies share common values such as adaptability, collaboration, and customer focus. They enable teams to respond to changing requirements, deliver value incrementally, and continuously learn and improve.
Here’s a short summary of some commonly used agile methodologies:
Scrum is one of the most popular agile frameworks. It involves dividing the work into small iterations called sprints, typically lasting 1-4 weeks. The team works collaboratively to deliver a potentially deliverable product increment at the end of each sprint. Daily stand-up meetings, backlog refinement, and sprint reviews are key components of Scrum. There are great resources to learn more, for example https://scrumguides.org/index.html.
Scrum is a great methodology for example for professional software development teams, but I have seen also successful applications in hybrid project context.
My favorite methodology for business development teams is Kanban.
Kanban emphasizes visualizing the workflow and managing work in progress (WIP) to optimize efficiency. Work items are represented as cards on a Kanban board, moving through different stages from “To Do” to “Done.” Teams pull new work items as they complete existing ones, ensuring a smooth flow of tasks. Kanban provides transparency and flexibility in managing priorities. A great resource to learn more about Kanban here: The official Kanban Guide. – Kanban Guides,
Lean is a great methodology for example for process or operations improvement initiatives, but also lean product management has become popular.
Lean methodology focuses on maximizing value while minimizing waste. It originated from the manufacturing industry and has been adapted widely for software development, too. Lean principles include eliminating unnecessary processes, reducing defects, empowering teams, and continuously improving the workflow. The goal is to create a streamlined and efficient process.
There are also several other popular methods, such as XP. Extreme Programming (XP) emphasizes close collaboration between developers, stakeholders, and customers. It emphasizes practices like continuous integration, test-driven development (TDD), pair programming, and frequent releases.
Ok, so these are commonly used agile methods, but how about continuous development, DevOps and other approaches linking to agile teams?
Different approaches for agile teams: Continuous development, DevOps & Agile project or program teams
In addition to methodology used, there is also the approach team has taken, such as Continuous development or Continuous improvement, DevOps, or other approaches linking to the ways of working.
A continuous development team is a group of individuals working together to deliver software or other outcomes in an iterative and continuous manner. This approach promotes fast and continuous delivery, enabling teams to respond quickly to changing requirements and market demands. Continuous development teams often utilize agile methodologies, automated testing, continuous integration and delivery pipelines, and collaborative tools to streamline the development process and ensure high-quality software releases.
Also business development may follow continuous development approach – developing, experimentation, collecting feedback, and further improving.
DevOps is a software development methodology that combines development (Dev) and operations (Ops) teams to streamline the software development and deployment process. It emphasizes collaboration, communication, and automation to achieve faster and more reliable software delivery. Learn more: “What Is DevOps? The Ultimate Guide”
From the development portfolio view point, DevOps team may be a bit challenging, as development and operations are combined seamlessly – how much are we investing into developing new and how much of the team work load is about keeping the business running?
In addition to continuous development teams or DevOps teams, also project or program teams may apply agile methodologies and ways of working. Based on a recent case study with 477 cross-industry projects, 52% of projects used a hybrid approach, including agile ways of working (Gemino et al, 2021).
So what is different in agile or hybrid projects?
In the traditional Waterfall project, the project triangle has fixed scope/features, time, and cost – and what would be variable – quality? The idea with agile or hybrid projects is to deliver a working solution within the given time, cost and with good enough quality. The number of features would be variable – and typically a recommended approach is to start with a delivery minimum viable project – a working solution with just the very basic functionalities.
But our team is unique – team topologies may help?
When discussing with different teams, there are many different types of teams. Of course, content is different, which is also reflecting to the way of working. One of my colleagues recommended to have a look at the Team topologies, I think this is useful to understand the nature of different types of teams:
Stream aligned team – developing a product and services, applications
Enabling teams – experts in certain area enabling work of other teams
Complicated sub-systems team – deep skills and expertise for example for a niche technology
Platform team – running platform as product and creating a great developer experience for other teams
In many organizations, adoption of agile methodologies has grown organically – resulting in a rich variety of ways of working and also sometimes difficulties to collaborate across different teams. I will cover briefly two popular enterprise agile frameworks: Large Scale Scrum (LeSS) and Scaled Agile Framework (SAFe):
Large Scale Scrum (LeSS)
When having multiple scrum teams, organizations may need to consider how to get organized. Large Scale Scrum (LeSS) has been developed to help with this. For really big organizations, LeSS Huge offers support to scale up. Tons of great material available via the LeSS pages: https://less.works/.
In the LeSS teams have certain key characteristics: teams are self managing and cross-functional, team members are 100% dedicated for work, and teams are co-located in the same room, and optimally teams would stay together forever (= long-lived teams). Teams are also managing external dependencies and make their own decisions. Team members are also multi-skilled, learning and adapting to changing needs. Read more about LeSS definition of team from here: link, also excellent recommended reading section provided.
Scaled Agile Framework – organizing around Value streams
Another popular framework to scale agile in enterprise is Scaled Agile Framework (SAFe). Scaled Agile Framework contains masses of good practices for different domains, and the trick would be to select the best ones fitting your organizations needs!
Within SAFe, there are also agile teams, and teams are organized as teams of agile teams, ARTs focusing on developing a value stream. What I especially like about SAFe, that also Lean portfolio management is included in the framework scope with many good practices. A SAFe portfolio is a collection of Value streams for specific business domain.
Conclusion & impact on development portfolios
Thank you for reaching to the end of such a long blog posting! Just final remarks: agile is not only about the methodologies, ways of working, frameworks and tools, even though these are also important, but about the mindset:
Delivering value to customers fast and continuously
Ability to respond to the change
Focusing on continuous improvement
In the context of development portfolios, it is important to understand how different teams in the organization work, and create transparency on portfolio level. More about Hybrid development portfolios combining projects and agile via separate blog post!
If every agile team has its own ways of working, it may be difficult to create portfolio-level transparency on all the great achievements throughout the organization. Also, increasingly large budgets are spent on agile development, and having clear guardrails and lean governance is important.
A. Gemino, B. H. Reich and P. M. Serrador, “Agile, Traditional, and Hybrid Approaches to Project Success: Is Hybrid a Poor Second Choice?,” Project Management Journal, vol. 52, no. 2, pp. 161-175, 2021.
Business agility refers to an organization’s ability to quickly and effectively respond to changes in the business environment – by being agile, organizations can adapt to change more effectively, capitalize on opportunities, and stay resilient in the face of disruptions.
Technology organizations have been working with agile methodologies for quite some time, but what does business agility mean in the context of strategic development portfolios?
1. Adapting to change
Adaptability to changes is an important benefit of business agility for development portfolios. Organization needs the capacity to anticipate and respond to market changes, customer needs, as well as emerging trends. An agile business is proactive in identifying opportunities and is willing to adjust its products, services, or operations accordingly.
Development portfolios can respond to changing priorities, market demands, and customer needs by adjusting the project portfolio content, timelines, and resourcing. If portfolio plans are fixed during the long range planning or yearly budgeting, it may be difficult to adapt to the change. One of the good practices I would recommend is portfolio reviews, see more via previous blog post: Time for a quarterly review?
2. Faster time to market
Agile approaches emphasize iterative development and frequent releases. By breaking projects and other initiatives into smaller, manageable chunks and delivering incremental value, agile enables faster time to market, allowing organization to seize market opportunities and gain a competitive edge.
So how to speed up development and go-to-market from the development portfolio view point?
Developing minimum viable product – being brave with prioritization of the content
Breaking down big initiatives into smaller, faster to implement work packages
Ensure smooth decision making – lean but powerful governance is blessing for the whole organization
Agile methodologies prioritize customer collaboration and feedback. By involving customers early and continuously throughout the development process, development portfolios can ensure that the delivered products or features align with customer expectations, resulting in higher customer satisfaction and loyalty.
Hearing the needs and feedback from the customers (or internal customers) is super important driver – and also reduces the risks of developing something, which is not actually valued by the customers and end-users. We may think we know what customers want and need, but do we really know if we don’t ask or validate the idea?
Customer engagement should be built into the development portfolio processes:
Do you co-create development concepts with customers? Do you validate the concepts with customers?
Do you have pilot customers to receive early feedback? Do you also have time to develop the solution based on the feedbacks?
Do you continuously collect feedback from the customers related to your products and services? Do you have a systematical process to analyze the feedbacks and take action?
Service design and growth hacking methods provide great support in this area!
4. Transparency
Agile methodologies promote transparency and visibility through practices like sprint reviews and demos. This enables stakeholders to have a clear view of project or team progress, impediments, and upcoming deliverables.
In the portfolio level creating transparency on agile team outcomes is also important – this may sometimes be a bit tricky, if the development portfolio has been mainly focusing on project portfolio view only. More ideas related to how to combine projects and agile available via the previous blog post: From project portfolios to hybrid portfolios – combining projects and agile work.
In the portfolio level, here are few topics to consider, when working with agile teams:
How much are we funding different agile teams?
Would there be a need to scale team capacity up or down in the future?
What does the high level roadmap look like for the agile team?
What are the key priorities and outcomes from each team for the next quarter?
How are different teams creating transparency across the organization for the great content delivered and also receiving the feedback (e.g. demos)?
5. Incremental benefit realization
One of the great benefits of agile approaches is delivery of smaller working products and solutions, which already enable benefit realization.
When compared to traditional waterfall development approaches with big-bang go-live, agile approaches may enable benefit realization for key parts of the delivery even years earlier. Over the time, this really adds up! If you have a massive transformation program with waterfall delivery, could you break down large entities to smaller incremental deliveries? This may not be always easy, but also reduces the risks of big-bang go-lives!
6. Reducing risk by learning fast
Agile embraces an iterative and incremental approach, allowing for early identification and mitigation of risks. By experimentation and feedback loop, it is possible to learn faster, and reduce the risks.
By regularly assessing and adapting development plans and priorities, development portfolios can address potential issues proactively, minimizing risks and maximizing project success.
Do you regularly discuss about the risks and also plan how to mitigate the risks?
Is it ok to kill a initiative in your organization, if you see, it is not commercially or technically fit for purpose?
Do you have experimentation culture to learn fast?
7. Collaboration – cross functional teams empowered with decision making
Promoting a culture of collaboration and cross-functional teamwork is crucial for business agility. This involves breaking down silos, fostering effective communication, and encouraging employees to share ideas and work together towards common goals.
By empowering teams to make decisions, collaborate closely, and take ownership of their work, development portfolios can foster a culture of innovation, creativity, and high performance. Here are few topics to consider:
Do you have truly cross functional teams?
Do you have clear guardrails for the team decision making?
What can be decided in the team level and which topics are decided in the portfolio level?
8. Continuous improvement
Embracing a mindset of continuous learning and improvement is fundamental to business agility. Agile organizations encourage experimentation, embrace failure as a learning opportunity, and constantly seek ways to enhance their processes, products, and services.
Agile promotes a culture of continuous learning and improvement. Development portfolios can regularly reflect on their processes, gather feedback, and implement changes to enhance efficiency, quality, and overall project outcomes.
Do you have feedback loops inbuilt for different development activities to collect the feedback, learn and improve?
Do you systematically collect and analyze development ideas and have capacity also for continuous improvement activities?
9. Resource utilization & prioritization
Agile methodologies emphasize prioritization, allowing development portfolios to focus on high-value initiatives and allocate resources accordingly. By optimizing resource utilization and reducing unnecessary work, Agile helps maximize productivity and ROI.
In practice, this also requires clear prioritization work in the portfolio level – which helps to create clarity and focus. More about the different prioritization methods for portfolios in a previous post: The Biggest Challenge For Development Portfolios is … Prioritization.
10. Employee engagement
Improved Employee Engagement and Satisfaction – agile methodologies empower team members, promote collaboration, and value individuals and interactions. This leads to increased employee engagement, job satisfaction, and retention within development portfolios.
This topic would require an own blog post in the future…
In the context of agile product management, the term “North Star” refers to a guiding principle or overarching goal that helps align the team’s efforts and provides a clear direction for product development. It is often used to define the ultimate vision or desired outcome of the product.
The concept of the North Star is derived from the metaphor of using the North Star as a navigational reference point. The North Star represents the long-term vision that the team strives to achieve. It serves as a constant reference point that guides decision-making and prioritization throughout the development process.
The North Star is typically a high-level objective that encapsulates the value proposition and core purpose of the product. It should be ambitious, and inspiring – allowing the team to track progress toward the desired outcome. While the North Star provides a clear direction, it also allows flexibility in how the team achieves the goal, as agile methodologies emphasize adaptability and iterative development.
Having a North Star helps the team stay focused, aligned, and motivated, especially in complex and fast-paced environments. It provides a common understanding of the product’s purpose and allows for better decision-making by aligning all stakeholders around a shared vision. Additionally, it serves as a reference point for evaluating the impact of product decisions and prioritizing work to ensure that efforts are aligned with the ultimate goal.
Even though the North Star concept has originated from product management, the same concept and thinking work well for strategic development portfolios and strategic initiatives – the long-term vision and guiding principle providing direction, alignment, and motivation for the team and stakeholders is super important!
Let’s have a look at the steps to identify your North Star!
Steps to Identify Your North Star
1. Understand the purpose
Begin by gaining a deep understanding of your product / development scope, its intended users, and the problem it solves. Clarify the purpose and value proposition. What is the core benefit it provides to users? How does it address their needs or pain points?
This understanding forms the foundation for defining the North Star!
2. Identify long-term goals
Think about the long-term goals or outcomes you want to achieve with your product. These goals should be ambitious, meaningful, and aligned with your product’s purpose. Consider the impact you want your product to have on users, the market, or the industry. Examples of long-term goals could include increasing user engagement, driving revenue growth, or becoming a market leader.
3. How to measure?
To ensure that the North Star is meaningful and trackable, it’s important to make it measurable. Define key metrics or indicators that can be used to gauge progress towards the North Star. For instance, if your goal is to increase user engagement, you could measure metrics like user retention, time spent in the product, or the number of active users.
Tip! Objectives and Key Results could be a great way to include also measurable key results with your North Star.
4. Align with stakeholders
Engage with relevant stakeholders, such as your product team, executives, customers, and any other key individuals or groups. Share your proposed North Star and seek their input and feedback. Ensure that the North Star resonates with their expectations, aligns with the overall business objectives, and reflects the needs and desires of your target users.
5. Iterate and refine
Defining the North Star is an iterative process. Gather feedback from stakeholders, evaluate its relevance and feasibility, and refine your definition accordingly. Iterate on the North Star until you reach a clear, compelling, and measurable goal that aligns with your product’s purpose and stakeholders’ expectations.
6. Communicate and share the North Star
Once you have defined the North Star, it’s crucial to communicate it effectively to your team and stakeholders. Ensure that everyone understands and embraces the North Star’s importance and how it guides decision-making. Regularly reinforce its relevance and progress to maintain alignment and motivation throughout the product development journey.
Remember, the North Star should be an aspirational goal that provides guidance and focus but allows for adaptability and iteration. It should inspire and motivate the team, align stakeholders, and ultimately drive the product’s success.
North Star – examples from leading companies for inspiration
The North Star may vary in wording and specificity across different sources and may evolve over time as companies adapt to new challenges and opportunities. Here are some examples of North Stars from leading companies:
Google: “Organize the world’s information and make it universally accessible and useful.”
Tesla: “Accelerate the world’s transition to sustainable energy.”
Airbnb: “Create a world where anyone can belong anywhere.”
Spotify: “Unlock the potential of human creativity.”
Amazon: “To be Earth’s most customer-centric company, where customers can find and discover anything they might want to buy online.”
Netflix: “Delight our customers with great content anytime, anywhere.”
Apple: “Design innovative products that enrich people’s lives.”
Conclusion
Defining an inspiring North star is not easy, and it may require also many discussions and alignment. Having a clear guiding principle and long term vision, the North Star, creates clarity for prioritization and ensures, we navigate to the correct direction, even though daily work may keep us busy with the details.
In the context of agile product management, the term “North Star” refers to a guiding principle or overarching goal that helps align the team’s efforts and provides a clear direction for product development. It is often used to define the ultimate vision or desired outcome of the product.
The concept of the North Star is derived from the metaphor of using the North Star as a navigational reference point. The North Star represents the long-term vision that the team strives to achieve. It serves as a constant reference point that guides decision-making and prioritization throughout the development process.
The North Star is typically a high-level objective that encapsulates the value proposition and core purpose of the product. It should be ambitious, and inspiring – allowing the team to track progress toward the desired outcome. While the North Star provides a clear direction, it also allows flexibility in how the team achieves the goal, as agile methodologies emphasize adaptability and iterative development.
Having a North Star helps the team stay focused, aligned, and motivated, especially in complex and fast-paced environments. It provides a common understanding of the product’s purpose and allows for better decision-making by aligning all stakeholders around a shared vision. Additionally, it serves as a reference point for evaluating the impact of product decisions and prioritizing work to ensure that efforts are aligned with the ultimate goal.
Even though the North Star concept has originated from product management, the same concept and thinking work well for strategic development portfolios and strategic initiatives – the long-term vision and guiding principle providing direction, alignment, and motivation for the team and stakeholders is super important!
Let’s have a look at the steps to identify your North Star!
Steps to Identify Your North Star
1. Understand the purpose
Begin by gaining a deep understanding of your product / development scope, its intended users, and the problem it solves. Clarify the purpose and value proposition. What is the core benefit it provides to users? How does it address their needs or pain points?
This understanding forms the foundation for defining the North Star!
2. Identify long-term goals
Think about the long-term goals or outcomes you want to achieve with your product. These goals should be ambitious, meaningful, and aligned with your product’s purpose. Consider the impact you want your product to have on users, the market, or the industry. Examples of long-term goals could include increasing user engagement, driving revenue growth, or becoming a market leader.
3. How to measure?
To ensure that the North Star is meaningful and trackable, it’s important to make it measurable. Define key metrics or indicators that can be used to gauge progress towards the North Star. For instance, if your goal is to increase user engagement, you could measure metrics like user retention, time spent in the product, or the number of active users.
Tip! Objectives and Key Results could be a great way to include also measurable key results with your North Star.
4. Align with stakeholders
Engage with relevant stakeholders, such as your product team, executives, customers, and any other key individuals or groups. Share your proposed North Star and seek their input and feedback. Ensure that the North Star resonates with their expectations, aligns with the overall business objectives, and reflects the needs and desires of your target users.
5. Iterate and refine
Defining the North Star is an iterative process. Gather feedback from stakeholders, evaluate its relevance and feasibility, and refine your definition accordingly. Iterate on the North Star until you reach a clear, compelling, and measurable goal that aligns with your product’s purpose and stakeholders’ expectations.
6. Communicate and share the North Star
Once you have defined the North Star, it’s crucial to communicate it effectively to your team and stakeholders. Ensure that everyone understands and embraces the North Star’s importance and how it guides decision-making. Regularly reinforce its relevance and progress to maintain alignment and motivation throughout the product development journey.
Remember, the North Star should be an aspirational goal that provides guidance and focus but allows for adaptability and iteration. It should inspire and motivate the team, align stakeholders, and ultimately drive the product’s success.
North Star – examples from leading companies for inspiration
The North Star may vary in wording and specificity across different sources and may evolve over time as companies adapt to new challenges and opportunities. Here are some examples of North Stars from leading companies:
Google: “Organize the world’s information and make it universally accessible and useful.”
Tesla: “Accelerate the world’s transition to sustainable energy.”
Airbnb: “Create a world where anyone can belong anywhere.”
Spotify: “Unlock the potential of human creativity.”
Amazon: “To be Earth’s most customer-centric company, where customers can find and discover anything they might want to buy online.”
Netflix: “Delight our customers with great content anytime, anywhere.”
Apple: “Design innovative products that enrich people’s lives.”
Conclusion
Defining an inspiring North star is not easy, and it may require also many discussions and alignment. Having a clear guiding principle and long term vision, the North Star, creates clarity for prioritization and ensures, we navigate to the correct direction, even though daily work may keep us busy with the details.
Strategic Portfolio Management 