Agile Product Team

Why Team Ownership Matters

Product ownership is one key factor in successful steering the direction of a product. It’s the capability for a team to autonomously shape and evolve their product based on a shared agreement. This autonomy, however, isn’t without responsibility; it demands accountability for the product’s trajectory and necessitates the use of methods and tools to forecast its future.

Product ownership in Agile methodologies offers a distinctive advantage – the ability to respond swiftly to change. Short feedback cycles empower teams to make informed decisions based on real-time data. This adaptability is crucial in a dynamic market where customer preferences and industry trends can shift rapidly. By minimizing external influence, teams gain the autonomy to collaboratively shape the product, aligning development efforts with Agile principles of flexibility and responsiveness.

Yet, autonomy in product ownership is a shared responsibility between the team and management. Agile coaches play a pivotal role in fostering the team’s willingness and capabilities to take ownership. Through coaching, they emphasize the intrinsic value derived from responsibility and accountability. Simultaneously, for autonomy to thrive, management must actively recognize and support the team’s ownership. Without such support, teams risk being relegated to mere executors of features rather than architects of innovative products. True empowerment emerges when the team’s autonomy is not just tolerated but actively supported, creating a culture of belief in the product throughout the organization.

Within Agile teams, a diverse mix of backgrounds, including software developers and those with product and customer experience, often prevails. However, the challenge lies in transitioning from a role focused on coding and feature implementation to actively deciding the product’s future. It’s not merely about coding proficiency; it’s about acquiring a holistic understanding of customers, market dynamics, competitors, and viable monetization strategies. The challenge is in broadening the team’s expertise beyond technical domains to encompass the intricacies of product strategy and market positioning.

In the traditional Agile landscape, product owners often hold sway in deciding the next feature. However, the full potential of an Agile team is unleashed when product owners consider the unique knowledge, skills, and time constraints of each team member. Agile product owners and coaches create an environment where developers are encouraged to take ownership. This collaborative approach is not just theoretical; it is actively communicated through various channels, such as speeches, blog posts, and daily interactions. Agile leadership finds its manifestation in routine Agile meetings like Scrum Daily and Scrum Refinement, providing platforms for inclusive decision-making and shared ownership.

While I think the advocated approach of seamless collaboration in decision-making and taking ownership as the 100% right way, I acknowledge the rarity of encountering this ideal scenario. It is my persuasive call to action. I urge readers, to explore and implement this approach within their teams and organizations. The emphasis lies on the potential benefits in product success and team satisfaction. While the ideal may be aspirational, the pursuit of enhanced ownership and collaboration promises tangible improvements in product outcomes and team dynamics.

Company benefits

When teams wholeheartedly embrace ownership of a product, companies stand to reap a myriad of benefits that extend far beyond the development phase. The alignment of the team’s collective focus with the success of the product becomes a catalyst for overall organizational growth. Here are some notable advantages:

Increased Accountability:

Teams taking ownership foster a culture of accountability. Each team member becomes more invested in the product’s success, leading to a heightened sense of responsibility for delivering high-quality results.

Enhanced Product Quality:

Ownership often translates to a deeper understanding of the product and its intricacies. Teams, when empowered, are more likely to strive for excellence, resulting in a product of higher quality that aligns closely with user needs.

Innovative Problem Solving:

An empowered team is more likely to approach challenges proactively. With ownership comes a sense of empowerment that encourages innovative problem-solving, enabling teams to navigate hurdles creatively and efficiently.

Improved Communication and Collaboration

Ownership fosters a collaborative environment where team members communicate effectively. Shared responsibility encourages open dialogue, leading to improved collaboration, knowledge sharing, and a more cohesive team dynamic.

Adaptability to Change

Teams with ownership are inherently more adaptable. The agile nature of product ownership allows for quick adjustments based on market changes or user feedback, ensuring the product remains relevant and competitive.

Efficient Decision-Making

With ownership, decision-making becomes more streamlined. Empowered teams can make decisions efficiently, avoiding unnecessary bureaucracy and delays. This agility is crucial in rapidly evolving markets.

Employee Satisfaction and Retention

Ownership over a product creates a sense of pride and accomplishment among team members. This increased job satisfaction contributes to higher employee retention rates, reducing the costs and challenges associated with employee turnover.

Customer-Centric Approach

Teams that take ownership inherently adopt a customer-centric mindset. They are more likely to empathize with users, resulting in products that genuinely address customer needs and preferences.

Faster Time-to-Market

Ownership accelerates the development process. Teams, empowered to make decisions, can respond promptly to market demands, ensuring faster time-to-market for new features or product releases.

Long-Term Product Vision

Teams with ownership are better positioned to contribute to the long-term vision of the product. Their understanding of user needs and market dynamics enables them to align development efforts with the broader strategic goals of the company.

In essence, a team that takes ownership of a product becomes a driving force for the company’s success. The synergy between individual commitment and organizational objectives creates a positive feedback loop, fostering an environment where innovation, collaboration, and adaptability thrive. The investment in empowering teams to take ownership pays dividends not only in the quality of the product but also in the sustained growth and resilience of the entire company.

Skills, Methods and Tools

Mastering a comprehensive set of skills, employing effective methods, and utilizing the right tools are paramount for success. A successful product ownership journey requires a strategic blend of technical proficiency, collaborative skills, and a toolbox equipped with methodologies tailored to understand user needs and market dynamics. In the following section, we delve into a curated list of skills, methods, and tools essential for teams aspiring to fulfil ownership of their products. These elements collectively empower teams to navigate challenges, make informed decisions, and drive product success in today’s competitive and ever-evolving market.

The journey towards product success is intricately tied to the ethos of team ownership. As we’ve explored the skills, methods, and tools that empower teams, it becomes evident that the benefits extend well beyond the realm of project completion. A culture of ownership not only enhances product quality, innovation, and adaptability but also contributes to a harmonious and motivated team dynamic. As we embrace the principles of agility and collaboration, let us recognize that true success lies in the hands of those who take ownership, driving excellence, and steering organizations towards sustained growth. Through collective empowerment, teams become architects of their own success, shaping a future where product triumphs are synonymous with the unwavering commitment of those who truly own their endeavors.

Agile Product

Navigating the Transition: Embracing Product-Centricity

Since I’ve started the journey as a scrum master I also accompany and feel the transition from a service oriented to a product centric environment. Since then, the disadvantages of a service-oriented approach have become increasingly apparent. Companies locked into this model often find themselves constrained by short-term, transactional thinking, limited scalability, and a lack of adaptability to changing market demands. The realization that a fundamental shift is needed sparks the journey toward a product-centric mindset. However, the path from service-oriented to product-centric is laden with challenges that extend far beyond the confines of software development and product management.

Departments across the organization, from sales and marketing to customer support, finance, operations, and human resources, must actively contribute to this transformation as the product is more than the software a company creates. This blog post delves into the challenges and pitfalls inherent in this shift, emphasizing the necessity for a holistic, collaborative effort. As we navigate the complexities of this transformation, we’ll explore the unique roles each department plays in overcoming obstacles and driving the organization towards a more agile, customer-focused, and sustainable future.

Product-led is driven by the following principle

As a product company, our entire process is driven by the imperative to create a product that can be sold to at least six customers to break even. This requirement is non-negotiable and emphasises the consistency and standardisation of our offering.

The Heart of the Change

The metamorphosis begins with a realization — a product is not merely about code; it’s a holistic entity that encompasses marketing, sales, and customer support. Unlike the service-centric ethos, where sales tailors solutions to customer needs, a product-centric approach demands selling the product as is, without or with much less customization. This shift poses a unique challenge for roles like customer consulting and project management, as their tasks undergo a fundamental transformation.

In this transformation, the development team becomes the nucleus, redefining the company’s DNA. The challenge is not just adapting the software but reshaping the mindset of the entire organization. Marketing, traditionally focused on portraying a service’s adaptability, must now convey the inherent strengths of the standardized product. Sales teams, accustomed to meeting unique customer demands, face the paradigm shift of selling not just a solution but a standardized product that solves common problems.

Shifting Perspectives: From Solution to Problem-Oriented

In the service-centric paradigm, customers often dictate the next software feature, providing a clear roadmap for development. However, in a product-centric world, the uncertainty of what features are next requires a fundamental shift in mindset. Departments must pivot from being solution-oriented to problem-oriented. This shift, though met with initial resistance, necessitates a collective understanding that every department must actively adapt to align with the product-centric vision.

As the development team grapples with the challenge of anticipating future features without explicit customer demands, sales and marketing find themselves in uncharted territory. Selling a standardized product means understanding and empathizing with the customer’s problems rather than tailoring solutions to specific needs. The organization becomes an expert problem-solver rather than a provider of bespoke solutions.

Every Department Counts

The product journey extends well beyond the confines of software development. It spans from the initial marketing touchpoints to the intricacies of key account management. For this journey to be successful, every department must play a vital role. Active participation is not a choice but a necessity. Failure to engage in the transformation leaves employees grappling with significant challenges, hindering their ability to contribute effectively.

In this holistic shift, marketing becomes the storyteller, crafting narratives that resonate with the standardized product’s strengths and benefits. Sales evolves into a consultative partner, guiding customers not just towards a purchase but towards a solution to their broader challenges. Customer support, once reactive to specific software customizations, transitions into a proactive force, preemptively addressing common issues and offering value-added services.

Pitfalls and Forecasts

Communication is the linchpin of successful transitions. One major pitfall lies in the fear of the unknown. Instead of providing false assurances that daily work won’t change, transparency is essential. Open and honest communication builds trust. Employees need a realistic forecast of the impending changes, encouraging them to actively participate in the transition, understanding that their contributions are valued and vital for success.

Addressing fears head-on requires leadership to acknowledge the challenges and uncertainties that accompany the transition. Offering a clear roadmap, outlining the expected changes, and providing support mechanisms can help alleviate anxiety. Forecasts should not sugarcoat the magnitude of the shift but should inspire confidence by emphasizing the collective capabilities of the organization to adapt and thrive in the new paradigm.

Customer Relationships: Navigating the Shift Together

Shifting from a service-oriented to a product-centric approach fundamentally alters the dynamics of customer relationships. Companies often fear customer reactions to standardized products over highly customized solutions. However, navigating this shift requires bringing customers along on the journey. Transparent communication is crucial. By informing customers of the transformative shift, businesses set clear expectations, fostering a collaborative relationship where customers understand the evolving nature of the partnership.

In this collaborative journey, companies must address the elephant in the room: the potential reduction in highly customized services. Transparency becomes a guiding principle as organizations educate customers about the benefits of standardized products. Emphasizing the value of best-in-class solutions and the organization’s expertise in delivering market-standard products builds trust. This shift is not just internal; it extends to creating a shared vision with customers, aligning expectations, and ensuring a mutually beneficial evolution of the relationship.

Revolutionizing the Sales Funnel in the Shift to Product-Centricity

In the dynamic landscape of a product-centric approach, the traditional sales funnel undergoes a profound transformation. Unlike the classical model where the product experience is an adjunct to the funnel, positioned alongside inquiries, marketing leads, opportunities, and customer engagement, the product-centric world seamlessly integrates the product experience as an integral part of the entire funnel.

Classical Approach: Product Experience as an Adjunct

In the classical sales funnel, the product experience often finds its place beside the funnel stages, with a linear progression from inquiries to marketing leads, opportunities, and customer engagement. The product, in this context, is perceived as a tool or solution that supports the sales process. It plays a role, but it’s not the central focus; instead, it complements the overarching goal of closing deals and satisfying customer needs.

Product-Centric Paradigm: A Paradigm Shift in the Funnel

In the product-centric world, the paradigm shifts fundamentally. The product experience is not relegated to a peripheral role but becomes a core and integrated component of the sales funnel. It exceeds the boundaries between marketing and sales, occupying a pivotal position that influences every stage of the customer journey.

Integral Role in Marketing: Elevating Product Experience

In the product-centric funnel, marketing is not just about creating awareness and generating leads; it becomes an avenue for showcasing the product experience. Marketing efforts are directed not only at attracting potential customers but also at immersing them in the essence of the product. From captivating visuals to interactive demonstrations, marketing materials are designed to convey the unique value proposition and the tangible benefits of the product.

Seamless Transition to Sales: Continuing the Experience

As leads progress through the funnel, the transition from marketing to sales is seamless, with the product experience continuing to play a central role. Sales teams are armed not only with information but with a compelling product narrative that has already begun during the marketing phase. This shift facilitates a more informed and engaged sales process, as customers have already experienced, to some extent, what the product has to offer.

Closing Deals with Enhanced Product Understanding

Opportunities and deals are no longer closed solely based on promises and proposals. Instead, they are sealed with a deeper understanding of the product gained throughout the funnel journey. Customers enter the final stages of the funnel not only convinced by the sales pitch but also having experienced the product’s features, benefits, and its alignment with their needs.

Post-Sale Integration: A Continuous Product Journey

In the post-sale phase, the product experience doesn’t end; it evolves into an ongoing journey. Customer engagement is not confined to troubleshooting or support; it extends to enhancing the product experience further. This cyclical relationship between product, marketing, and sales ensures that each customer interaction becomes an opportunity to strengthen the product-centric bond.

In embracing a product-centric approach, companies revolutionize the sales funnel. The product experience, once a mere appendage, becomes a driving force. This integrated funnel not only elevates marketing and sales processes but also ensures that every customer interaction is an immersive experience, forging lasting connections and driving sustained success in the product-centric landscape.

In the transformative journey from a service-oriented to a product-centric approach, the role of an Agile coach becomes paramount. Agile coaches act as catalysts for change, leveraging their expertise to facilitate the transition towards a more responsive and customer-focused organizational structure. Shifting to a product-centric model often introduces uncertainties, especially for teams accustomed to the predictability of service-oriented approaches. Agile coaches excel in navigating uncertainty, instilling Agile principles that embrace change and value customer feedback. Their guidance helps teams adapt to the dynamic nature of product development. Agile coaches champion the concept of continuous improvement. Through regular retrospectives and feedback loops, they enable teams to reflect on their product development processes. By fostering an environment where teams can iterate towards greater efficiency, Agile coaches contribute significantly to the success of the product-centric shift.

Agile Product Roadmap

From Backlog to Brilliance: Crafting a Product-Centric Roadmap

In today’s exploration, we’re diving headfirst into the art of crafting a roadmap that not only navigates the complex waters of agile development but places your product at the heart of every decision. Say goodbye to feature-driven roadmaps and hello to a customer-centric, problem-solving approach.
1. Keeping it Customer-Centric:
When it comes to crafting a product-centric roadmap, the key is to keep your ear to the ground—more specifically, to your customers. Sure, you could create a roadmap from an insider’s perspective, or you could take a more customer-centric approach. The magic happens when you ask your customers what problems they need solving. Avoid the temptation to dive into solution mode; instead, linger in the problem zone. Customers tend to articulate their desires in terms of solutions, but the true brilliance lies in understanding the underlying problems. Remember, it’s not about what features you deliver but about the problems you solve sustainably.
2. Navigating the Agile Seas:
In the realm of agile development, navigating trade-offs is an art form. Our approach? A departure from feature-based roadmaps. A customer-centric roadmap should be laden with problems to solve rather than features to deliver. This shift in perspective makes it easier to prioritize and decide which problems demand immediate attention. Dates and timelines? Not so fast. Instead of locking yourself into a rigid schedule, consider categorizing items as ‚first,‘ ’next,‘ and ‚after.‘ This flexibility allows your team to move at a pace that aligns with the dynamic nature of agile development.
3. Real-world Reality Check:
Now, let’s ground these ideas with a real-world reality check. Unfortunately, I don’t have a success story to share from my own experiences—why? Because, more often than not, the environments I’ve worked in were dominated by feature-based roadmaps with strict timelines. And, predictably, they failed to deliver on those promises. The company’s inability to fulfill roadmap items within the given timelines highlighted a significant flaw in the traditional approach.
Here lies the crux of the matter: A well-crafted product-centric roadmap might not have graced my past endeavors, but the need for it resonates more strongly than ever. The agile development landscape thrives on adaptability, responsiveness, and a relentless focus on solving customer problems. It’s time to bid farewell to the rigidity of feature-based roadmaps and embrace the flexibility and effectiveness of a roadmap rooted in addressing real problems.
In conclusion, when crafting your roadmap, don’t just think features—think problems. Your customers will thank you, and your agile journey will be all the more brilliant.

Agile Product

From User Stories to Product Features: Bridging the Gap in Agile

Bridging the gap between user stories and tangible product features is a nuanced and essential process. It requires careful navigation to ensure the user’s original intent remains intact while fitting within the structured sprint or iteration cycles that Agile teams follow. Let’s explore the intricacies of this journey.

Working within agile sprints or iteration cycles is a fundamental principle, but user stories often don’t align seamlessly with these timelines. Users usually can’t validate a feature’s value until the entire story is implemented. This necessitates collaboration between the product manager and the development team to dissect user stories into smaller, manageable segments that fit within sprint timeframes. While challenging, this process is critical for maintaining agility.

Another common challenge arises when feature requests are inundated with technical specifications, or when users primarily describe the features, they want rather than articulating the problems they wish to solve. To ensure that delivered features align not only with user intent but also with problem resolution, it’s crucial for user stories to remain firmly in the problem space, rather than diving headfirst into the solution space. This approach often requires a series of in-depth interviews to truly comprehend the underlying issues at hand.

Furthermore, it’s not uncommon for users to present specific feature requests, leading to the initial writing of user stories that cater to these requests. However, by refining user stories and transitioning from the solution space to the problem space, development teams can uncover existing features that were previously unknown to the user. This discovery can be a powerful way to efficiently deliver value within an Agile context, by making the most of what’s already available.

Staying in the Problem Space

Within this complex landscape, the Scrum Master plays a pivotal role in ensuring user stories are written effectively. Developers may lean towards wanting explicit instructions on what to implement, rather than delving into the problems to be solved. Yet, this approach may not always lead to the best solutions. The Scrum Master’s primary responsibility is to raise awareness about this challenge and promote open-minded discussions within the team. The best solutions invariably emerge from the collective expertise and insights of a skilled team, rather than relying solely on a single product owner.

To enhance this dynamic, Scrum Masters often need to shift their focus from coaching teams to a more profound understanding of the product the team is developing, especially if they lack a technical background. By actively engaging in discussions about the product, asking pertinent questions, and immersing themselves in the team’s dialogues, Scrum Masters can better guide the team towards the creation of more effective user stories and, consequently, more successful product development outcomes.

In conclusion, the journey from user stories to product features within Agile software development demands a well-thought-out approach. It encompasses breaking down user stories to fit within Agile iterations, shifting the focus from technical details to problem-solving, and unveiling previously unnoticed solutions. The Scrum Master’s role is central in steering the team towards crafting better user stories and ensuring more effective product development. Broadening their perspective to include a deeper understanding of the product domain can lead to improved collaboration and superior outcomes in Agile projects.

Agile Product

Success vs performance in agile software development

Agile software development is a popular and effective approach to software development that emphasizes collaboration, adaptability, and customer satisfaction. In agile, success is defined as the ability to deliver high-quality software that meets the customer’s needs, within the expected timeline and budget.

Success in agile software development is different from performance. Performance refers to how well the team can execute the development process, including how fast they can deliver new features and how efficiently they can resolve bugs and issues. Success, on the other hand, is measured by the impact of the software on the customer’s business, such as increased revenue, improved customer satisfaction, or reduced operational costs.

In agile software development, the primary focus is on delivering value to the customer rather than shipping a high number of features. This is because delivering functional software that meets the customer’s needs is ultimately more important than delivering many features that may not add significant value.

When developing software, it is important to prioritize the features that will provide the most value to the customer. This requires understanding the customer’s needs, identifying the most important features, and delivering those features as quickly and efficiently as possible. In some cases, this may mean delivering a smaller number of features, but ensuring that those features are of high quality and provide significant value to the customer.

By prioritizing value over quantity, the development team can ensure that they are delivering software that meets the customer’s needs and provides real business value. This approach can also help to reduce development costs, as it allows the team to focus on the most important features and avoid spending time and resources on less important or unnecessary features.

Another benefit of focusing on value over quantity is that it can lead to greater customer satisfaction and loyalty. By delivering software that meets the customer’s needs and provides real business value, the development team can build strong relationships with their customers and earn their trust and loyalty. This can help to ensure ongoing business and revenue opportunities for the organization.

Delivering high value to customers and measuring successcan be challenging, but it is essential for evaluating the effectiveness of the development process and identifying areas for improvement. There are several metrics that can be used to measure success in agile.

Customer satisfaction

Customer satisfaction is a critical factor in measuring the success of agile software development because it directly reflects the extent to which the software meets the needs of the customer. Agile software development is centred around the idea of delivering value to the customer, and customer satisfaction is a key indicator of whether this value has been delivered.

Measuring customer satisfaction involves soliciting feedback from customers and evaluating their responses to determine how well the software meets their needs. This feedback can take many forms, including surveys, focus groups, user testing, and customer support interactions. By collecting and analysing this feedback, the development team can gain valuable insights into the features and functionality that are most important to their customers and identify areas where improvements are needed.

Customer satisfaction is important for several reasons. First, it is a direct reflection of the quality of the software and the extent to which it meets the needs of the customer. If customers are satisfied with the software, it is a strong indicator that the development team is delivering value and meeting customer needs effectively.

Second, customer satisfaction is critical for building customer loyalty and ensuring ongoing business opportunities. Customers who are satisfied with the software are more likely to continue using it, recommend it to others, and engage in ongoing business with the organization. This can help to drive revenue and ensure ongoing growth and success.

Finally, measuring customer satisfaction can help to identify areas for improvement in the development process. By soliciting feedback and evaluating customer responses, the development team can identify areas where the software is not meeting customer needs effectively and make adjustments to improve the software and ensure greater customer satisfaction in the future.

Time to market

Time-to-market is a valuable indicator for success in agile software development because it reflects the organization’s ability to deliver software quickly and efficiently, which is a key goal of agile development methodologies. Agile development emphasizes the importance of delivering functional software quickly and frequently, with the aim of providing value to the customer as soon as possible.

By measuring time-to-market, the development team can evaluate how well they are meeting this goal and identify areas where improvements can be made. A faster time-to-market indicates that the organization can deliver value to the customer more quickly, which can provide a competitive advantage in the marketplace.

In addition, a faster time-to-market can also help to reduce costs and improve efficiency. By delivering software quickly, the organization can reduce the time and resources required for development, testing, and deployment, which can help to reduce costs and increase productivity. This can help the organization to operate more efficiently and effectively, which can lead to greater profitability and growth.

Business impact

A high business impact is an important factor for measuring the success of agile development because it reflects the extent to which the software is delivering value to the organization. Agile development is focused on delivering software that meets the needs of the customer and provides real business value, and a high business impact is a key indicator that this value is being delivered.

Measuring the business impact involves evaluating the effect that the software has on the organization’s key performance indicators (KPIs) and bottom line. This can include factors such as increased revenue, improved efficiency and productivity, cost savings, and customer retention. By measuring the impact of the software on these metrics, the organization can determine how well the software is meeting business objectives and delivering value to the organization.

A high business impact is important for several reasons. First, it is a direct reflection of the effectiveness of the software in meeting business objectives and delivering value to the organization. If the software is driving positive results and contributing to the success of the organization, it is a strong indicator that the development team is delivering value and meeting business needs effectively.

Second, a high business impact is critical for driving ongoing investment and support for the software development process. If the software is delivering significant business value, it is more likely that the organization will invest in ongoing development and support, ensuring that the software continues to meet evolving business needs and remain competitive in the marketplace.

Finally, measuring the business impact can help to identify areas for improvement in the development process. By evaluating the impact of the software on key business metrics, the development team can identify areas where the software is not meeting business needs effectively and make adjustments to improve the software and ensure greater business impact in the future.

In conclusion, a high business impact is an important factor for measuring the success of agile development. It reflects the extent to which the software is delivering value to the organization, is critical for driving ongoing investment and support for the development process, and can help to identify areas for improvement in the development process. As such, it should be a key focus for any organization that is committed to delivering high-quality software and providing value to their business.

The product manager is in the best position to deliver success metrics for agile development because they have a deep understanding of both the customer’s needs and the organization’s business objectives. As the person responsible for defining the product vision, strategy, and roadmap, the product manager has a clear understanding of the goals and objectives that the software is intended to achieve, as well as the features and functionality that are most important to the customer.

Because of this deep understanding, the product manager is uniquely positioned to identify and define the key success metrics for the software development process. They can work with the development team to establish metrics that are aligned with the product vision and strategy, and that reflect the value that the software is intended to deliver to the customer and the organization.

In addition to defining success metrics, the product manager is also responsible for monitoring and reporting on progress towards those metrics throughout the development process. They can use tools such as customer feedback, user testing, and data analytics to track progress and identify areas where improvements are needed and can communicate this information to stakeholders and the development team in a way that is clear and actionable.

The scrum master can also play a role in measuring performance and success by facilitating team retrospectives and identifying areas for improvement in the development process. The CTO may be responsible for setting high-level goals and objectives for the development team, but measuring success and performance should be the responsibility of the product owner.

In conclusion, success in agile software development is defined by the ability to deliver high-quality software that meets the customer’s needs within the expected timeline and budget. Success is different from performance, which refers to how well the team executes the development process. Measuring success can be challenging, but metrics such as customer satisfaction, time to market, quality, and business impact can be used to evaluate the effectiveness of the development process. The product owner is best positioned to measure success, but the scrum master and CTO can also play a role in evaluating performance and identifying areas for improvement.


How to apply product-led principles to modernize outdated software systems

Legacy software systems can be a major headache for organizations that rely on them to run their business operations. These systems are often outdated, complex, and difficult to maintain, making it difficult to keep up with modern software development practices. However, product-led development methodologies can provide a solution for modernizing legacy systems. In this article, we will discuss how to apply product-led principles to modernize outdated software systems.

Legacy systems refer to outdated software systems that are still in use by an organization. These systems are often built on outdated technology and lack modern software development practices. They may be difficult to maintain and upgrade due to their complexity and interdependencies. These systems can be a major roadblock to innovation and can cause major issues when they fail.

Product-led development methodologies can provide a solution for modernizing legacy systems. Here are some ways to apply product-led principles to legacy systems.

Start with Customer Discovery

The first step in product-led development is to understand the needs and problems of the end-users. This might sound easy at first because you already do have customers using your product. The problem will be to find out which problem your software is solving. Customers will be certainly able to tell you which feature set they are using, but the question to ask is: Why.

In the context of legacy system modernization, it’s important to understand how the legacy system is currently meeting the needs of the end-users, what are the current pain points, and how they would like the system to be improved. This information can help guide the modernization efforts and ensure that the end-users’ needs are met.

This can be done through various user research methods, such as surveys, interviews, or usability tests.

Define Clear Goals and Priorities

Clear goals and priorities should be defined for the modernization project. The goals should align with the overall business strategy and consider the limitations and constraints of the legacy system. It’s important to prioritize the needs of the end-users and ensure that the modernization efforts are focused on providing value to them. Clear goals and priorities help to ensure that the modernization project stays on track and that the efforts are focused on the most important areas.

Leverage Agile Development

Agile development is an iterative development process that focuses on delivering small, incremental changes. This approach can be applied to modernizing legacy systems by breaking down the system into small, manageable pieces and focusing on one piece at a time. Agile development helps to ensure that the modernization efforts are focused, and that progress is being made in a timely manner. It also helps to ensure that the modernized system is meeting the needs of the end-users.

This step might be the biggest change for your customers. In an agile approach your customer is heavily involved in the whole development process as they know best if your product is solving any of their problems. Very often this expanded customer interactions is new for both the software developers and the customer. But the change will be worth it, as you gain understanding of the customers problems, and your customers trust in solving them.

Measure Success with Metrics

Metrics are used to track the performance of the product and the impact it has on the end-users. This approach can be applied to modernizing legacy systems by setting up metrics that track the impact of the new features or designs on the end-users. Metrics can help to ensure that the modernized system is providing value to the end-users and that the modernization efforts are on track. They can also help to identify areas for improvement and guide future modernization efforts.

Product Lifecycle Agreement

The product lifecycle strategy for legacy products in a product-led development involves managing the product from its introduction to the market to its eventual end-of-life (EOL) phase. Legacy products are those that have been in the market for a long time and may no longer be actively developed or maintained but are still in use by a significant user base. Managing the product lifecycle of legacy products is essential to ensure that they continue to meet user needs and evolve with changing technologies. While the lifecycle of a product generally includes introduction and growth phases the focus for legacy products will be on the maturity and end-of-life phase. In the maturity stage, the product’s growth slows down as it reaches its peak level of adoption. The goal of this stage is to maintain the product’s market share and profitability by focusing on cost reduction and efficient production. During this stage, product development may be focused on maintaining the product’s reliability and stability, as well as addressing any compatibility or security issues that may arise. In the end-of-life stage, the product is no longer actively developed or maintained, but may still be in use by a significant user base. The goal of this stage is to manage the product’s EOL in a way that minimizes disruption for users and maximizes the value of the product for the company. During this stage, the company may consider offering support and maintenance services to existing users, as well as providing recommendations for alternative products or upgrades.

It is important to have a transparent and well communicated (for developers as well as customers) product lifecycle plan. For legacy products it is very important to have and idea of the end-of-life. Without a clear end-of-life strategy customers will either request innovation and change on a product you cannot maintain any more or just leave your product portfolio at all because the market will easily overtake you.

Product-led development can provide a solution for modernizing legacy systems by focusing on the needs, desires, and problems of the end-users. Starting with customer discovery, defining clear goals and priorities, focusing on leveraging agile development, and measuring success with metrics can all help to ensure a successful modernization project. By taking a product-led approach to legacy system modernization, organizations can become more efficient, reduce costs, and stay ahead of the competition.

Agile Product

5 essentials you should consider when writing a user story.

In software development a user story is a request to change or add behaviour to the product. Although the scrum guide does not mention user stories, they are widely considered as being part of the agile software development. Writing good user stories is a key aspect of delivering high value to the customer. Investing time in writing a good user story leads to spending less time in the development phase and is therefore simply a matter of cost. In this article I will give you five essential hints to write better user stories and therefore to ease the delivery of high value to your customer.

Who writes user stories?

Although it is the responsibility of the product owner that a backlog of user stories exists the product owner is not the sole writer of stories, a user story can be written by anyone.

Therefore, the given hints should be followed by everybody who feels the need to contribute to the products increment.

1. Write the story from user perspective

The software that you are going to deliver is for some user. Hence what is closer than to write the desired change from that user’s perspective. It is therefore needed that any story writer truly understands how a user interacts with the current increment as well as the user might interact with the future increment as well. Consequently, it is essential for a story writer and especially for a product owner is to get in contact with their users and their customers.

As a user might not be available at any time a helpful tool might be so called personas. A persona is a virtual user of your product which somehow shows a stereotype[1]. Use these stereotypes to identify different types of users and their different needs. Personas are a good starting point to understand the audience of your product.

[1] https://medium.com/beakerandflint/personas-74c4e1c12ee2

2. Write stories collectively

In the software development work, pair programming is known to deliver high quality implementations as there are four eyes looking at the changes done. The interaction and the exchange of ideas as well as critical thinking about the work of others on the go really puts some focus of the outcome (rather then the output). This kind of collaboration can be easily adopted to story writing as well. Having two writers instead a sole person, will boost the creativity of the story creation process and will lead to a well thought story, looking at aspects of the story a single person could not even imagine.

3. Don’t stick to the happy path only

In the creation of a story the writer might think about what a user wants to achieve by using the desired function. The writer describes the happy path in which the user is going to do all necessary steps correctly and in the correct order. Additionally, all preconditions are set correctly. Sadly, this will never reflect the real world. In the real world what can go wrong will go wrong. Thus, the unhappy path of working with the product needs to be part of the user story as well. Describe what needs to happen if the user did not meet the preconditions or even what might happen if the product itself did not react as you expect.

  • What should the error message contain?
  • How should the product behave in case of an unexpected error?
  • Which options did the user have in case he made a mistake?

4. The user story is the main input for QA

An important part of product development is quality assurance[1]. Within the quality assurance the development team checks whether the implementation matches the needs of the user. These needs are written down as part of the user story. Surely the product knowledge can be used as an entry point for quality assurance, but it needs to have some “truth” to compare to. The user story is an essential source for this truth.

Therefore, the QA process does not start at the end of the life cycle of a product change but already in the process of creating the user story. This guarantees to not only deliver quick and frequent changes to the user, but real value that can make the users life better.

[1] https://medium.com/p/9fabd1f6c66e

5. Technical details should be added by the developer

As already mentioned, writing the user story is not the sole responsibility of the story writer nor the product owner. It is truly essential that the story is complete and understandable by anybody when you start implementing it. That means that the development team needs to contribute to the story. In many cases the development team knows their product very well and get help to deliver the best value to its customers.

But as already said, the user story is written from a user centric view and needs to be understood by anybody in the chain of product delivery. This concludes that too much technical details should not be part of the story itself. Also, it is not in the responsibility of the story writer nor the product owner to deliver the technical details needed to implement the story.

Technical details are surely needed to implement a story correctly, but they are not part of the story itself. They should be added as part of a task. A task beneath the story is the right place to note the details needed for a good implementation. A story describes what is needed. The task beneath describes how it can be done.


Why Quality and Innovation Suffer in a Feature Factory Approach

In successful software development is it widely accepted that the best outcome is produced by autonomous development teams having their own product and a clear target. This means that a successful software development team can find out and to decide about how to change the product to deliver real value. The team’s product might be part of a bigger solution, but the team does not need to share the product with another team to reduce dependencies. They also have a clear product goal (could be addressed using OKR). This way a team feels responsible for their work and will deliver high quality features that meet the need of their products customers.

In contrast a lot of software development team are primarily feature factories. As a feature factory the team has little to no influence on the product as the product decisions are made by managers outside of the team. For a feature factory team, the output is more important than the outcome. Managers do not really ask the team to deliver features the team thinks the customer needs. Instead, they ask the team to implement the feature in the pace the manager estimated.

Less quality

One of the main difficulties of software development is delivering software of high quality. You can deliver cheap software with a high pace. Customer might buy it, but they will not stay if your product lack of quality. If you want a team to deliver quality, you need to get the team feel accountable for what they produce. In a feature factory where the team merely does what they have been told to do and not what they are convinced to be the right thing, the team will hardly deliver quality. The work produced will just be the output of the requirement. It will not be an outcome of high quality.

Less innovation

If a company uses its development teams solely for coding, they drop a big part of the possibility to innovate. Today, technology is at a point where customers can hardly imagine what is possible within the product. Therefore, engineers are a big source of innovation as they know what can possibly be done. In a feature factory environment, the development team has little influence on how the product evolves. The product change will be decided outside of the product team. In this case a company will not use the innovative potential a development team can deliver.

Less efficiency

The highest cost in product development is the work on production ready code. The more you can make sure that what you are going to build really is what will be needed afterwards the more time and money you save. A feature factory leaves out the part where the team is going to focus on what really will match the needs of a customer and will deliver a real value to the product. A feature factory team focuses on the forecasted output instead of the outcome. They need to deliver something fast instead of delivering the real thing a bit slower. Hence you do need more iterations to match customer needs, or you need to live with unhappy customers.

Less responsibility

We need teams of missionaries, not teams of mercenaries.[1]

Developing a product which fits the market you need teams of missionaries, not teams of mercenaries. If you give the decision about the product to the team, they will feel responsible for the product. A team that feels responsible for what they deliver will deliver a high-quality product. They will deliver you the innovation that is needed to stay ahead of your competitors and they will work efficiently as they focus on coding what is really needed and what really creates value.

Mercenaries will leave the team as soon as there will be any problem. Missionaries will stay with you through thick and thin times.

A feature factory team will maybe follow the directions given by managers, but they will not feel the pain of customers as well as colleagues. They just do what they’ve been told. No more, no less.

[1] https://www.svpg.com/missionaries-vs-mercenaries/


From Features to Outcomes: Why to Build a Outcome Based Product Roadmap

Managers want to make sure that everybody knows what the top priority is.

I can totally share this need as it is crucial to know what is currently important. The first reflex is often to create a roadmap, which contains the most important projects of the future in a particular order. But a product roadmap does not only address the goal to know what is important now, but also what will be important after the first item and even what will be important in a couple of months.

Additionally, to knowing what will be important in the future you also plan how to solve the problems of the future with your current knowledge. This suggest that you do not only have an idea what will be important in a couple of weeks but also how to tackle the problems of the future as classical roadmaps do not address the upcoming challenges but solutions instead.

The problem of planning solutions ahead is that you cannot be sure that these solutions really match the problem. Hence with finishing the roadmap item you can totally celebrate releasing it, but you have no idea which problem is solved now. Without knowing which problem has been solved you cannot be sure that you have created any value. I prefer knowing the problem to solve instead of having a solution.

Instead of using a roadmap full of assumptions of solutions, the better idea would be to have a roadmap full of problems you want to solve in the future. This way you can make sure everybody can focus on solving the most urgent problem.

In his must-read book “Inspired” Marty Cagan says that such an outcome-based roadmap is “is all about solving problems, not implementing features” [1].

An outcome-based roadmap does not state the next feature to implement but the next problem to solve. This way you do not only create real value, but you also have a possibility to measure your progress. Instead of measuring the delivery and accept upcoming work to get the feature to its full potential, you can be sure to deliver value from the very start.

Hence instead of planning to have a newly styled onboarding page you should rather plan to achieve an increase of new customers, more customer satisfaction in the onboarding or easier onboarding for people with disabilities. That gives you and your team the chance to achieve the goal in the most propriate way and the most suitable technology available. Furthermore, you can easy check if the implementation you have chosen did have any impact on your goal. Instead of celebrating the release of a feature you can celebrate the increase of new customers. Which goal looks more valuable to you?

In the phase of transition, it is tough to move from a classical project roadmap to an outcome-based roadmap in just one big step. But if you are looking for a low hanging fruit to the approach you can easily write down the purpose for any planned roadmap item. You can then use the known planning approach of a classical roadmap with additional goals to achieve and move slowly to an outcome-based roadmap.

One of the key benefits of an outcome-based roadmap is that it helps to align the product development efforts with the overall business goals and strategies. By focusing on the desired outcomes, teams can make sure that they are working on the most important and impactful areas of the product. It can also help to ensure that resources are being used effectively and efficiently to achieve the desired outcomes.

Additionally, it gives everybody on the company to fully understand why their work has an impact to the overall goal.

[1] Marty Cagan, INSPIRED: How to Create Tech Products Customers Love


Why Good Product Management Matters: Key Indicators to Look For

Good product management decides about the success of a product and therefore often about the success of the total company. In the very beginning of a company, you mostly try to please just a few customers and they drive the change of the product. But as a company grows and customers pleasing everybody does not scale very well. Different customer groups do have different expectations on the product. Hence you need to make sure that your product evolves in the right direction pleasing the right lucrative customers. If you want to please everyone you will not deliver value for anyone in the long run.

At this point a good product management needs to take over to decide about the development of the product. Which part needs to grow, which parts needs to modernize, and which needs to be phased out. A product manager can take the decisions based on knowledge about various aspects of the product using multiple skills and technics. Seven very important aspects of good product management are mentioned in this article. Following these aspects will give a good start on the path to a good product management and concluding a good product.

1 Product managers know the goals of the company.

Product managers are responsible for their product. They make decisions about new features, modernization as well as removal of functionality. Any product decision needs to support the overall company goals. It can be the goal to gain new customers or to make a specific customer group happier by solving their specific problems. It can be a goal to reach a certain level of cloud compatibility or to make the customer onboarding process as easy as possible. Whatever the company goals are each product manager needs to know and internalize the goals. Product manager align the product development based on the goals and make sure to focus on achieving the goals. Additionally, product managers need to have the commitment that long term company goals are important enough to really work on them. Not aligning the product to the company goals and you will never achieve your goals, but instead have a bouquet of product features that do not match each other.

2 Product managers know the business of the company.

Product managers understand the economic value the company’s product create for the products users and the company itself. To be precise product managers need to know the amount of money the company makes by selling a specific part of the product. How much money does the company make by selling a specific module or feature set, how much does the customer pay to use a specific service. Without this knowledge the product management did not have the chance to produce value for the company. Instead, they create costly change that will not sell very well.

3 Product managers do know the products customer.

Knowing the customer is key knowledge for every product manager. You need to know the motivation to use your product and especially the problem your product solves and needs to solve in the future. Product managers need to experience the usage of their product as close from the real user as possible. In a business-to-business environment you also need to know the decision maker regarding the sales process of your software. Without knowledge of your customers problems, you will be trapped thinking within the solution space. Instead, you should think within the problem space of your customers. Product managers need to ask how the feature solves a problem for the customers.

Product managers find solutions for the problems customers and therefore allow every team member to create value working on the company’s product.

4 Product managers know the product.

A company’s product can be very complex. A lot of features, subproducts, modules, … have been created in the company’s history. Product managers need to be the expert when it comes to their team’s product and the company’s product. Without this knowledge the company will spend money on developing features twice or even three times. Additionally, you will develop features that customers already rejected in the past.

Using this product knowledge, product managers modernize and expand the product where necessary and refrain where possible.

5 Product managers make their decisions based on the market, competitors, and actual trends.

Product management does not happen in a happy bubble with no influence from the outside world. Instead, various factors from outside do need to influence the decision-making process regarding your company. It may be the competitor, that does have this one killer feature that your product is missing. Without the knowledge about this you will wonder why you do not sell your product well, but your competitor does.

Additionally, you need to know about the market. Which group of companies in the market do you currently address? What is the rest of the market and what will be needed to address their issues as well. Without this knowledge you will evolve your software, but nobody will need it, or you will try to please anybody because you do not understand that there is a market for your product.

6 Product managers communicate decisions about the product development.

Product managers make decisions daily. They decide which experiments to start, which feature to implement and very important which feature not to implement. Any decision regarding the direction a product evolves need to be transparent to the whole company. Your colleagues need to know why their requested feature has not been implemented they way they expected. Your developer needs to know about your decisions to implement it right. Product management is no ivory tower. Product managers need to tell the how and why of their decisions.

The transparency gained allows everybody to focus on achieving the product goals.

7 Product managers decide about the creation as well as the discontinuation of products.

When it comes to the new creation of a product the idea might come from any part of the company. But in the end, it is the product manager who need to decide if the new product will fit in the companies, customers, and market context.

High level managers tend to take the decision on their own and force the product manager to follow their way. Only the product manager does have the necessary background information.

Additionally, product managers decide about the end of live of a product. They know if there will be a valuable market in the future and if the product will stay maintainable.

8 Product managers know technics and tools

Decisions taken by a product manager need to be comprehensible and reliable. The best way to achieve this is using best practice techniques and tools to get all the data needed to understand product, market, competitors, and company. This way at least a sufficient number of decisions can be retraced later.

Product managers use data driven decisions to deal with the unexpected (e.g. experiments and agility).