A Conversation with Dean Leffingwell and Geoffrey Moore

Safe Business Agility Podcast Cover Image

In 1995, author and advisor Geoffrey Moore released Inside the Tornado, the second book in his popular three-part marketing series that offers strategies to get products into the mainstream market. Twenty-five years later, is the guidance in the book still relevant? In this episode, Dean Leffingwell takes over the mic to find out from the author himself—and to ask some other burning questions.

Click the “Subscribe” button to subscribe to the SAFe Business Agility podcast on Apple Podcasts

Share:

In 1995, author and advisor Geoffrey Moore released Inside the Tornado. It was the second book in his popular three-part marketing series that offers strategies to get products into the mainstream market. And it’s a book that Dean says he learned a lot from at the time. Twenty-five years later, is the guidance in the book still relevant? In this episode, Dean Leffingwell takes over the mic to find out from the author himself—and to ask some other burning questions, including what Inside the Tornado 2.0 would cover.

Visit these links to learn more about the following topics referenced in the podcast:

Hosted by: Melissa Reeve

Melissa Reeve is the Vice President of Marketing at Scaled Agile

Melissa Reeve is the Vice President of Marketing at Scaled Agile, Inc. In this role, Melissa guides the marketing team, helping people better understand Scaled Agile, the Scaled Agile Framework (SAFe) and its mission.

Guest: Dean Leffingwell

Recognized as one of the world’s foremost authorities on Lean-Agile best practices, Dean Leffingwell is an author, entrepreneur, and software development methodologist.

His two best-selling books, Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise, and Scaling Software Agility: Best Practices for Large Enterprises, form much of the basis of modern thinking on Lean-Agile practices and principles. Founder of several successful startups, including Requisite, Inc., makers of RequisitePro (acquired by Rational), Mr. Leffingwell also served as Chief Methodologist to Rally Software, and prior to that, as a Sr. Vice President at Rational Software (now part of IBM). He currently serves as Chief Methodologist to Scaled Agile, Inc., which he co-founded in 2011.

Guest: Geoffrey Moore

Geoffrey Moore is an author, speaker, and advisor who splits his consulting time between start-up companies and established high-tech enterprises. His life’s work has focused on the market dynamics surrounding disruptive innovations.

Learn more about Geoffery on LinkedIn

Why the Most Successful PMs and POs Share a Brain – Implementing SAFe Successfully

In SAFe®, the Product Owner (PO) and Product Manager (PM) roles are critical for many reasons. We’ll start with the basics, the why, and the roles and responsibilities of each.

Product Owner (PO) and Product Manager (PM) roles

POs and PMs are essential to the success of SAFe. While they share areas of concern, both have their own focus. They both care about the Continuous Delivery Pipeline, they both iterate, and they both have content authority around their backlogs. They’re both responsible for continuous improvement, ensuring capacity for the architectural runway, communicating and collaborating on the vision and roadmaps, and much more.

And, they both focus on execution.

The PM leverages Customer Centricity and Design Thinking to reason about product enhancements, new product ideas, as well as innovation. The PO focuses on flow for development, release execution, and incremental delivery. And, they both embrace the Continuous Delivery Pipeline and the DevOps mindset. 

But there’s another element to the importance of their roles: their relationship with each other. The most successful POs and PMs share a brain.

There are many aspects to why this matters, so let’s synthesize them into three main “whys.”

Product Owner (PO) and Product Manager (PM) roles

Knowledge transfer, information coherence, and flow

OK, that’s actually three in one, but I put them together for a reason. These roles share a common goal. To inspire and transfer knowledge from the brains of who’s closest to the customer (PMs, Business Owners, etc.), into the brains of those responsible for execution (POs and teams). And, they need to do this with the highest possible level of information coherence, while removing delays and achieving flow.

Here’s an example from a recent PI Planning event I attended. The first day went swimmingly. The management problem solving workshop resulted in six adjustments to planning that were designed to help the teams. The PM spent 30 minutes kicking off day two talking about the adjustments and not too many people asked questions. But during the breakouts, all hell broke loose. The PM texted me saying, “I don’t think they heard a word I said!” The teams and POs argued about the changes, and this caused total chaos. All of which resulted in a huge “flow stoppage” to the entire PI Planning event. Looking back, I realized that the PM didn’t socialize the changes with the POs before day two kicked off, and the POs hadn’t bought into the shift. This completely interrupted any knowledge transfer and information coherence. Why did this happen? Because the PM and POs didn’t share a brain around the changes.

Transparency, content authority around their respective backlogs, and decentralized decision making

SAFe is a series of connected work items, some represented in Kanban, and others represented simply as backlogs. The Team backlogs are a combination of work being pulled from the Program Backlog with work from the local context. With that content, authority comes great responsibility to the product or solution, as well as the enterprise. The Program Backlog comes into PI Planning in the form of economically prioritized work items (Features).

Product Management leveraged their stakeholder management network as input to prioritize the work so that the teams can pull work for the PI that has the highest value to the business. The team backlog comes into PI Planning in the form of capacity allocated for other work items (maintenance, exploration, etc.), and is also prioritized, but slightly differently. The team backlogs are prioritized mostly for flow and execution of the value being pulled, which doesn’t necessarily align directly to the actual WSJF of the Program Backlog. 

For this to work, POs and PMs need early transparency into both sets of backlogs so they can make Lean and Agile decisions around the work, and maintain content authority around their respective backlogs. In other words, they need to share a brain around all of the work. Specifically, what capacity allocation are we recommending for maintenance? For refactoring? For exploration? And for new Feature development? What if something happens? What are our working agreements? By sharing a brain around these aspects and working agreements, POs and PMs can make real-time decisions as well as decisions around the backlog in which they have content authority.

Sharing a brain builds trust

We know that an environment that has trust creates a sense of safety for everyone involved. When PMs and POs really start sharing a brain and trusting each other to make decisions, magic happens. This is probably last on our list, as it’s the foundation for the previous two “whys.” 

Product Owner (PO) and Product Manager (PM) roles

I’ve been fortunate enough to have shared a brain with a few awesome PMs. And the impact of these relationships had real quantitative value. For example, literally anyone on the train could ask either of us a question and they’d get the same answer. This was so incredibly powerful. No more delays in answers or direction. No deviation from the vision. While of course we always want to encourage divergent thinking, there are always aspects of the backlog that have a strong answer (and direction), and others that could use a more collaborative approach. Knowing that both of us could be trusted to have the same answer controlled any backlash, but also created that sense of trust. The teams literally saw us as one, and whether the answer was: “I need to collaborate with my PM,” or a “specific answer,” they trusted us both implicitly. Just as we trusted the teams to deliver, they became extremely predictable in delivering against their objectives. This bi-directional trust not only helped us achieve our highest value in the shortest amount of time, but it created behavior models for others throughout the enterprise to follow. 

The How

Now that we’ve discussed the why, let’s look at the how. How the heck do PMs and POs actually share a brain? 

Well, it starts with some “symbiotic-ness,” First, having a common passion around the work creates some synchronicity as well as symbiosis. Then, learn to like each other, evolve, and explore common interests. Eventually, if enough time, emotional intelligence, and willingness occur, the PM and PO grow to love each other. This creates the ability to have extremely healthy dialogue, heated debate with no attachments to preconceived outcomes, and of course, that brain sharing.

Start with something simple. Get to know each other. Ask about each other’s family, their values, and their personal aspirations. Make lunch dates and keep them. Share food, common interests, and personal time. Realize that a successful relationship relies on true personal connections, not just what happens at work.

Here’s another example. After working with one particular PM for some time, her house burned down. The CEO of the company called me to let me know, and specifically asked that I didn’t call her. Well, at that point, we had shared such a deep relationship that I asked myself, “What would she want me to do?” She would want me to call her. So, I did. Together, we cried. She shared what she was going through. Of course, I offered to help in any way I could. She said that just the kindness of the gesture was enough for now, and that she promised she would ask for help when she got through the trauma and devastation at hand. 

None of that could have happened without the power and evolution of our POPM relationship. Sharing a brain. Getting to know each other. Sharing knowledge and understanding. Being transparent, while playing our own roles on the train. Creating trust within the organization that anyone could ask either of us a question and get the same answers. All this may seem like the soft stuff, but it’s how we grow our social networks, our relationships, and open up to share ideas, values, and opinions on how to deliver the highest value to our customers and society. 

After all, who doesn’t want that?

Check out these articles to get different perspectives about PO and PM roles, responsibilities, and relationships:

About Jennifer Fawcett

Jennifer Fawcett - a retired, empathetic Lean and Agile leader

Jennifer is a retired, empathetic Lean and Agile leader, practitioner, coach, speaker, and consultant. A SAFe Fellow, she has contributed to and helped develop SAFe content and courseware. Her passion and focus has been in delivering value in the workplace and by creating communities and culture through effective product management, product ownership, executive portfolio coaching, and leadership. She has provided dedicated service in these areas to technology companies for over 35 years.

View all posts by Jennifer Fawcett

Share:

Back to: All Blog Posts

Next: SAFe and Business Architecture

Understanding Leading Indicators in Product Development and Innovation

It’s quite common for people to nod knowingly when you mention leading indicators, but in reality, few people understand them. I believe people struggle with leading indicators because they are counterintuitive, and because lagging indicators are so ingrained in our current ways of working. So, let’s explore leading indicators: what they are, why they’re important, how they’re different from what you use today, and how you can use them to improve your innovation and product development.

What Are Leading and Lagging Indicators?

Leading Indicators in Product Development

Leading indicators (or leading metrics) are a way of measuring things today with a level of confidence that we’re heading in the right direction and that our destination is still desirable. They are in-process measures that we think will correlate to successful outcomes later. In essence, they help us predict the future.

In contrast, lagging indicators measure past performance. They look backwards and measure what has already happened.

Take the example of customer experience (CX). This is a lagging indicator for your business because the customer has to have the experience before you can measure it. While it’s great to understand how your customers perceive your service, by the time you discover it sucks it might be too late to do anything about it.

ROI is another example of a lagging indicator: you have to invest in a project ahead of time but cannot calculate its returns until it’s completed. In days gone by you might have worked on a new product and spent many millions, only to discover the market didn’t want it and your ROI was poor.

Online retailers looking for leading indicators of CX might look instead at page load time, successful customer journeys, or the number of transactions that failed and ended up with customer service. I often tell clients that if these leading indicators are positive, we have reason to believe that CX, when measured, will also be positive.

Don Reinertsen shares a common example of leading vs. lagging indicators: the size of an airport security line is a leading indicator for the lagging indicator of the time it takes to pass through security screening. This makes sense because if there is a large line ahead of you, the time it will take to get through security and out the other side will be longer. We can only measure the total cycle time once we’ve experienced it.

If you operate in a SAFe® context, the success of a new train PI planning (which is a lagging indicator) is predicated on leading indicators like identifying key roles, training people, getting leadership buy-in, refining your backlog, socializing it with the teams, etc.

Simple Examples of Successful Leading Indicators

The Tesla presales process is a perfect example of how to develop leading indicators for ROI. Tesla takes refundable deposits, or pre-orders, months if not years before delivering the car to their customers. Well before the cars have gone to production, the company has a demonstrated indicator of demand for its vehicles.

Back in the 90s, Zappos was experimenting with selling shoes online in the burgeoning world of e-commerce. They used a model of making a loss on every shoe sold (by not holding stock and buying retail) as a leading indicator that an online shoe selling business would be successful before investing in the necessary infrastructure you might expect to operate in this industry.

If you are truly innovating (versus using innovation as an excuse for justifying product development antipatterns, like ignoring the customer) then the use of leading indicators can be a key contributor to your innovation accounting processes. In his best-selling book, The Lean Startup, Eric Ries explains this concept. If you can demonstrate that your idea is moving forward by using validated learning to prove problems exist, then customers will show interest before you even have a product to sell. Likewise, as Dantar P. Oosterwal demonstrated in his book, The Lean Machine, a pattern of purchase orders can be a leading indicator of product development and market success.

Leading Indicators Can Be Near-term Lagging Indicators

Let’s loop back and consider the definitions of leading and lagging indicators.

  • Lagging: Measures output of an activity. Likely to be easy to measure, as you’ve potentially already got measurement in place.
  • Leading: Measures inputs to the activity. Often harder to measure as you likely do not do this today.

Think about the process of trying to lose weight. Weight loss is a lagging indicator, but calories consumed and exercise performed are leading indicators, or inputs to the desired outcome of losing weight.

Leading Indicators in Product Development

While it’s true that both calories consumed and exercise performed are activities that cannot be measured until they’re completed, and therefore might be considered near-term lagging indicators, they become leading indicators because we’re using them on the path to long-term lagging indicators. Think back to the CX example: page load time, successful customer journeys, and failed transactions that end up with customer service can all be considered near-term lagging indicators. Yet we can use them as leading indicators on a pathway to a long-term lagging indicator, CX.

How to Ideate Your Leading Indicators

The most successful approach I’ve applied with clients over many years is based on some work by Mario Moreira, with whom I worked many moons ago. I’ve tweaked the language and application a little and recommend you create a Pathway of Leading to Lagging Indicators. To demonstrate this, I will return to the CX example.

Ideate Leading Indicators

If we walk the pathway, we can estimate that an acceptable page load time will lead to a successful user journey, which—if acceptable—will then lead to fewer failed transactions that revert to customer service, which ultimately will lead to a positive customer experience metric.

Work Backwards from Your Lagging Indicator

To create your Leading to Lagging Pathway, start from your lagging indicator and work backwards looking at key successful elements that need to be true to allow your lagging indicator to be successful.

At this stage, these are all presuppositions; as in, we believe these to be true. They stay this way until you’ve collected data and can validate your pathway. This is similar to how you need to validate personas when you first create them.

Add Feedback Loop Cycle Times

Once you have your pathway mapped out, walk the pathway forward from your first leading indicator and discuss how often you can and should record, analyze, and take action for that measure. You should make these feedback loops as short as possible because the longer the loop, the longer it will take you to learn.

Feedback Loop Cycle

All that’s left is to implement your Leading to Lagging Pathway. You may find a mix of measures, some which you measure today and some you don’t. For those you already do measure, you may not be measuring them often enough. You also need to put in place business processes to analyze and take action. Remember that if measures do not drive decisions, then your actions are a waste of resources.

Your leading indicator might be a simple MVP. Tools like QuickMVP can support the implementation of a Tesla-style landing page to take pre-orders from your customers.

Applying Leading Indicators in Agile Product Management

A common anti-pattern I see in many product management functions is a solution looking for a problem. These are the sorts of pet projects that consume huge amounts of R&D budget and barely move the needle on profitability. Using design thinking and Lean Startup techniques can help you to validate the underlying problem, determine the best solution, and identify whether it’s desired by your potential customers and is something you can deliver profitably.

In SAFe, leading indicators are an important element of your epic benefit hypothesis statement. Leading indicators can give you a preview of the likelihood that your epic hypothesis will be proven, and they can help deliver this insight much earlier than if you weren’t using them. Insight allows you to pivot at an earlier stage, saving considerable time and money. By diverting spending to where it will give a better return, you are living by SAFe principle number one, Take an economic view.

Let’s look at some working examples demonstrating the use of leading indicators.

Leading Indicators in Agile Product Management
Leading Indicators in Agile Product Management
Leading Indicators in Agile Product Management
Leading Indicators in Agile Product Management

I hope you can now see that leading indicators are very powerful and versatile, although not always obvious when you start using them. Start with your ideation by creating a Leading to Lagging Pathway, working back from your desired lagging indicator. If you get stuck, recall that near-term lagging indicators can be used as leading indicators on your pathway too. Finally, don’t feel you need to do this alone, pair or get a group of people together to walk through this process, the discussions will likely be valuable in creating alignment in addition to the output.

Let me know how you get on. Find me on the SAFe Community Platform and LinkedIn.

About Glenn Smith

Glenn Smith

Glenn Smith is SAFe Program Consultant Trainer (SPCT), SPC, and RTE working for Radtac as a consultant and trainer out of the UK. He is a techie at heart, now with a people and process focus supporting organizations globally to improve how they operate in a Lean-Agile way. You will find him regularly talking at conferences and writing about his experiences to share his knowledge.

View all posts by Glenn Smith

Share:

Back to: All Blog Posts

Next: Traits of the Stoic Agilist

Shared Objectives and Collaborative Sense Making: Key to Success

product owners (POs) and product managers (PMs)

Welcome to the third post in our series about best practices to create a healthy relationship between product owners (POs) and product managers (PMs) that drives product success. You can check out the previous post here.

In this post, we’ll dive into examples of how you might find yourself in the feature In this post, we’ll dive into examples of how you might find yourself in the feature factory described in our first post. Plus, we’ll offer some thoughts about how to get back to strong PO/PM relationships and focus on delivering value.

Scenario One: Who are you talking to?

Picture this: You’re a PM at a company that’s designing a new app. In the spirit of customer centricity, you’re actively getting feedback. You’re regularly talking to a couple of hyper-engaged customers from Company X. It’s a large company and you’ve got a strong relationship with one of their internal champions who’s easy to get in touch with. During one of these customer feedback sessions, a developer on your team joins the call, too. Afterwards, while you’re confident things are headed in the right direction, your developer wonders out loud why the customer thinks to feature A is great if she really hasn’t used it yet.

Contacting the same customer for feedback on every new thing your company is working on isn’t the best approach. Why? If you’re not careful, you might end up thinking about her as representative of all the rest of your customers with the same job title. That’s likely not the case, so you should also be talking to customers at different companies with different needs for whatever it is you’re building. Another thing to think about: if it’s just you talking to the same customer all the time, you’ll often believe that your organization is always building the right thing. Inviting other people in your organization to collaborate with you on those customer calls might uncover a different perspective, as your developer did in the previous scenario. Having those two or three perspectives in the room is greater as a whole than as individual viewpoints.

Scenario Two: What are you measuring?

product owners (POs) and product managers (PMs)

Picture this: Your organization developed a page on a website and is seeing 20 percent user adoption on that page. As the PM, you think that’s successful because you’re hitting a key performance indicator (KPI) revealing that 20 percent of people logging in are using the page. But your PO feels that’s not necessarily true because the metric represents the same handful of people logging in, not 20 percent of overall users, which is how they interpreted the KPI of “20-percent adoption.” To address the data conflict, you and the PO look at the feature to see what the details of the KPI were. Turns out there aren’t any details, nor is there any mention of baseline metrics. So, neither of you know if the page was successful or not, or if you should pivot or persevere, or what to compare the data to. And the team’s efforts turned into a feature factory because the goals were really about getting the features out the door instead of the goals themselves.

It seems really apparent that PMs and POs need to agree on what measurements translate to a successful outcome, and how they’ll be tracked and interpreted. But we often skip over that part, just assuming all that will be obvious when the time comes. But actually, that assumption often leads to data conflicts. Aligning on metrics is hard work. You may not even know exactly how to measure success yet and you might have to slow down before you speed up, but agreement is critical to avoid future data conflicts.

Get smart 

The same applies to determining the goal of the work and the value to the customer using SMART objectives. Many of us are familiar with these. But really, how often do you and the team take the time to get alignment and a clear, shared understanding of all the details of your objective? Is it specific, measurable, achievable, realistic, and time-bound (SMART)? Or is it just specific but not measurable?

And remember, it’s ok to fail, as long as you’re learning and applying what you learn to improve. The learning part is only possible in a culture that allows for failure, for example, where you’re not hitting the metrics. It’s a culture where people don’t feel the need to mess with the data or avoid committing to a measure from the beginning. It’s part of the innovation process to fail. If the culture doesn’t allow for that, then you’ll get a culture of people that skip that step on purpose to make it look like they’re successful..

The trap of the feature factory is easy to fall into. I hope now that you have a clear path to: 

  • Improve how you collect and perceive customer feedback
  • Write clearer KPIs with baseline metrics
  • Clearly define and align on SMART goals across teams

Armed with this information, you can better recognize the trap, and use your PO/PM relationship to stay out of it. 

Check back soon for another post in our PO/PM success series.

About Lieschen Gargano Quilling

Lieschen Gargano is an Agile coach

Lieschen Gargano is an Agile coach and conflict guru—thanks in part to her master’s degree in conflict resolution. As the scrum master for the marketing team at Scaled Agile, Lieschen loves cultivating new ideas and approaches to Agile to keep things fresh and exciting. She also has a passion for developing best practices for happy teams to deliver value in both development and non-technical environments. Fun fact? “I’m the only person I know of who’s been a scrum master and a scrum half on a rugby team.”

View all posts by Lieschen Gargano Quilling

Share:

Back to: All Blog Posts

Next: Agility Fuel

POs and PMs: A Dynamic Duo

Welcome to the second post in our series about best practices to create a healthy relationship between product owners and product managers that drives product success. You can read the first post here.

I’ve heard lots of metaphors used to describe the relationship between a product owner (PO) and a product manager (PM). One of my favorites is oil and vinegar—separately, they’re just liquid on a salad, but mix them together and you’ve got a great dressing.

POs and PMs - A Dynamic Duo

A PO and a PM working together creates a positive tension that leads to a great relationship—despite different opinions—that’s in others’ best interests. But combining the PO and PM into one role is a recipe for disaster. 

I know because I experienced the trouble firsthand.

Think about the core responsibilities for both roles:

  • Be the voice of the customer
  • Analyze data
  • Manage backlogs
  • Make customers happy
  • Organize cross-team syncs
  • Create roadmaps
  • Support planning
  • Seek out competitive intelligence
  • Aid support escalations
  • Help sales activities

One person simply can’t do all these activities in a typical work week. When I’ve been in this situation, I found that the urgent, tactical things come first as people clamor for responses, feedback, and direction on their daily work—ultimately causing important strategies to suffer. Some days, I’d already made two to three stressful decisions before morning tea and was expected to make more at strategic levels. I quickly experienced decision fatigue. When your company and solution are small, you might be able to do it all, but it doesn’t scale.

There’s a strong stereotype that PMs need to be mini CEOs and be just as stressed out. That’s not sustainable as a product person. When a PM is also doing the work of a PO, expecting them to do strategy and manage the team backlog throughout the PI isn’t realistic. You miss the strategic work, you miss pivot-or-persevere opportunities. I’d often ask myself, “Am I really looking at the big picture or just surviving?” 

The power of an Agile team is that it’s a high-functioning group that collaborates. And when the PO and PM roles are performed by two different people, they can work together to support those teams, and ultimately, the organization. When I was a PO working with a PM to deliver a new onboarding experience for our product, we stayed in sync. I focused on what our technology allowed and what the team could implement. She focused on market impact and educating our sales team. We had healthy, productive conversations with positive conflict about what should happen next, and split the duties of attending meetings. All while continuing our business-as-usual activities and still finding time to recharge for the next day.

POs and PMs - A Dynamic Duo

If you’re a leader, avoid having one person take on both roles. If you’re doing both of these jobs, don’t. Perhaps there’s someone in your organization who can help you by serving informally in the other role. Finding the balance that I just described is key to your and your product’s success. POs and PMs don’t have to be in the same places but they need to connect, be aligned, and maintain that positive tension. It’s why we teach these roles together in our SAFe POPM class—you need to know how to best collaborate with your peer PO or PM to excel.

If you’re free on August 26 at 6:00 PM MDT, join Lieschen and I at an online Agile Boulder meetup where we’ll talk about this very topic.

Check back soon for the next post in our series about shared objectives and collaborative ‘sense making.’

About William Kammersell

William Kammersell

William Kammersell is a Product Manager and SAFe® Program Consultant (SPC) at Scaled Agile. With over a decade in Agile software development, he loves researching customer problems to deliver valuable solutions and sharing his passion for product development with others. William’s journey as a developer, scrum master, Agile coach, product owner, and product manager has led him through a variety of B2B and B2C industries such as foreign language learning, email marketing, and government contracting.

View all posts by William Kammersell

Share:

Back to: All Blog Posts

Next: How Planview Executed a Successful, Virtual PI Planning

Product Owners, Product Managers, and the Feature Factory

Product Owners and Product Managers

Both product owners (POs) and product managers (PMs) have “product” in their titles. Both roles connect people to the customer to ensure we’re building the right thing. Both roles rely on data to inform decisions and spot trends by correlating that data to everything that’s going on across the organization. Both roles manage backlogs. And both roles make customers happy. So, what’s the difference between a PO and a PM?

Product managers concentrate on the program backlog and features, look one to three program increments ahead, and focus on product viability. They collaborate with business owners and those at the solution and strategic levels within SAFe®

Product owners concentrate on the team backlog and stories, look one to three months ahead, collaborate with the team, and focus on product feasibility.

Seems straightforward enough, but we’ve heard feedback from people in the field that the PO-PM structure within SAFe isn’t so great.

“I’ve trained dozens of teams who are using SAFe and I have never seen this work well. The Product Owners are disconnected from their users and incapable of creating effective solutions for them that really solve their problems, because they do not understand the problems well. The Product Managers are essentially ‘waterfalling’ down the requirements to them and the teams are not allowed to prove if these are the right things to build or not. No one is doing validation work.” 

—Melissa Perri, Product Manager vs. Product Owner

The feature factory

What’s described above is something many call “the feature factory.” Organizations quickly fall into the feature-factory trap when POs stop talking to external customers, going with the word of the PM instead and losing sight of the user’s needs. It also happens when PMs become disconnected from the teams, choosing to write requirements that are handed off to POs instead of aligning with teams and POs on objectives about how to best achieve them. By not connecting with the team, over time, PMs start making all the decisions on their own and there’s no room for teams to provide ideas to their own backlogs—essentially ‘waterfalling’ their PIs as described above and creating a culture of meeting acceptance criteria instead of focusing on objectives. 

We often also see feature factories when PMs and POs never say “no” to requests from customers or business owners. Catering to the desires of a few large clients or to executives’ individual objectives can cause PMs and POs to drop validation work and strategy in response to those requests. Without validation work, there aren’t any clear pivot-or-persevere moments for checking in to see if we’re understanding the problem correctly or even solving their problems. Instead, we’re practicing waterfall and calling it SAFe.

In this blog series, William Kammersell, our curriculum product manager, and I will share practices to help you avoid the feature factory and create a healthy PO-PM relationship that drives product success.

Read the next post in the series here.

About Lieschen Gargano Quilling

Lieschen Gargano is an Agile Coach

Lieschen Gargano is an Agile coach and conflict guru—thanks in part to her master’s degree in conflict resolution. As the scrum master for the marketing team at Scaled Agile, Lieschen loves cultivating new ideas and approaches to Agile to keep things fresh and exciting. She also has a passion for developing best practices for happy teams to deliver value in both development and non-technical environments. Fun fact? “I’m the only person I know of who’s been a scrum master and a scrum half on a rugby team.”

View all posts by Lieschen Gargano Quilling

Share:

Back to: All Blog Posts

Next: Elevate Your Remote Production to Super Awesome

Deep Dive: Journey to Design Thinking – Business Agility Planning

Safe Business Agility

In this Deep Dive episode of the SAFe Business Agility podcast, Melissa Reeve, SPC and Joe Vallone, SPCT and SAFe Fellow, explore design thinking, its nuances and how organizations can take the journey from a traditional product development approach to an approach driven by Customer Centricity and Design Thinking.

Click the “Subscribe” button to subscribe to the SAFe Business Agility podcast on Apple Podcasts

Share:

Hosted by: Melissa Reeve

Melissa Reeve is the Vice President of Marketing at Scaled Agile

Melissa Reeve is the Vice President of Marketing at Scaled Agile, Inc. In this role, Melissa guides the marketing team, helping people better understand Scaled Agile, the Scaled Agile Framework (SAFe) and its mission.

Hosted by: Joe Vallone

Joe Vallone is an experienced Agile Coach and Trainer

Joe Vallone is an experienced Agile Coach and Trainer and has been involved in the Lean and Agile communities since 2002. Mr. Vallone has helped coach several large-scale Agile transitions at Zynga, Apple, Microsoft, VCE, Nokia, AT&T, and American Airlines. Prior to founding Agile Business Connect, Joe Vallone served as an Agile Coach at Ciber, CTO/CIO of We The People, and the VP of Engineering for Telogical Systems.

Benefits of Adopting Lean-Agile UX into a SAFe Implementation

Safe Business Agility

Learn the benefits of adopting Lean-Agile UX into a SAFe implementation and how to balance the roles of the PO, PM and Business Owners in this podcast episode. We’ll also be addressing leadership agility and how servant leadership differs from traditional leadership and common antipatterns when writing PI Objectives.

Click the “Subscribe” button to subscribe to the SAFe Business Agility podcast on Apple Podcasts

Share:

SAFe in the News

Three things we learnt about integrating UX design into the Scaled Agile Framework, SAFe

By Jennifer Fabrizi and River Brandon

Full article

  • Learn about the “zone of happiness” where product management, business technology and design converge.
  • How to shift the product team’s mental model from work being a feature factory to being more of a learning ecosystem that we share with one another.
  • The importance of creating a culture of shared responsibility

Learn more about how SAFe addresses Lean UX by visiting scaledagileframework.com/lean-ux/.

SAFe in the Trenches

Hear Jennifer Fawcett, one of the leading experts on the Product Manager/Product Owner role in SAFe shares an example where the PM/PO and BO roles got out of balance and how the organization worked to get them back in balance.

Check out the new Agile Product Management course at scaledagile.com

Audio CoP

The Audio Community of Practice section of the show is where we answer YOUR most frequently asked and submitted questions. If you have a question for us to answer on air, please send it to podcast@scaledagile.com

The two questions we answer in this episode are:

  • Lean-Agile Leadership is a foundational concept in SAFe. How does this mindset – and a servant leadership mindset in general – differs from a traditional mindset?
  • What makes PI Objectives tricky and what are some of the common antipatterns that our listeners can avoid?

Hosted by: Melissa Reeve

Melissa Reeve is the Vice President of Marketing at Scaled Agile

Melissa Reeve is the Vice President of Marketing at Scaled Agile, Inc. In this role, Melissa guides the marketing team, helping people better understand Scaled Agile, the Scaled Agile Framework (SAFe) and its mission.

Hosted by: Joe Vallone

Joe Vallone is an experienced Agile Coach and Trainer

Joe Vallone is an experienced Agile Coach and Trainer and has been involved in the Lean and Agile communities since 2002. Mr. Vallone has helped coach several large-scale Agile transitions at Zynga, Apple, Microsoft, VCE, Nokia, AT&T, and American Airlines. Prior to founding Agile Business Connect, Joe Vallone served as an Agile Coach at Ciber, CTO/CIO of We The People, and the VP of Engineering for Telogical Systems.

Adopting Lean-Agile UX – Scaled Agile

Safe Business Agility

Learn the benefits of adopting Lean-Agile UX into a SAFe implementation and how to balance the roles of the PO, PM and Business Owners. We’ll also be addressing how servant leadership differs from traditional leadership and common antipatterns when writing PI Objectives.

Click the “Subscribe” button to subscribe to the SAFe Business Agility podcast on Apple Podcasts

Share:

SAFe in the News

Three things we learnt about integrating UX design into the Scaled Agile Framework, SAFe

By Jennifer Fabrizi and River Brandon

Full article

  • Learn about the “zone of happiness” where product management, business technology and design converge.
  • How to shift the product team’s mental model from work being a feature factory to being more of a learning ecosystem that we share with one another.
  • The importance of creating a culture of shared responsibility

Learn more about how SAFe addresses Lean UX by visiting scaledagileframework.com/lean-ux/.

SAFe in the Trenches

Hear Jennifer Fawcett, one of the leading experts on the Product Manager/Product Owner role in SAFe shares an example where the PM/PO and BO roles got out of balance and how the organization worked to get them back in balance.

Check out the new Agile Product Management course at scaledagile.com

Audio CoP

The Audio Community of Practice section of the show is where we answer YOUR most frequently asked and submitted questions. If you have a question for us to answer on air, please send it to podcast@scaledagile.com

The two questions we answer in this episode are:

  • Lean-Agile Leadership is a foundational concept in SAFe. How does this mindset – and a servant leadership mindset in general – differs from a traditional mindset?
  • What makes PI Objectives tricky and what are some of the common antipatterns that our listeners can avoid?

Hosted by: Melissa Reeve

Melissa Reeve is the Vice President of Marketing at Scaled Agile

Melissa Reeve is the Vice President of Marketing at Scaled Agile, Inc. In this role, Melissa guides the marketing team, helping people better understand Scaled Agile, the Scaled Agile Framework (SAFe) and its mission.

Hosted by: Joe Vallone

Joe Vallone is an experienced Agile Coach and Trainer

Joe Vallone is an experienced Agile Coach and Trainer and has been involved in the Lean and Agile communities since 2002. Mr. Vallone has helped coach several large-scale Agile transitions at Zynga, Apple, Microsoft, VCE, Nokia, AT&T, and American Airlines. Prior to founding Agile Business Connect, Joe Vallone served as an Agile Coach at Ciber, CTO/CIO of We The People, and the VP of Engineering for Telogical Systems.

What’s a Product Owner to Do?

Product Owner

When I coach companies on Lean and Agile methodologies, I strive to have dedicated, co-located Product Owners (POs), Scrum Masters, and teams. In the 21st century and given our current context, many companies involved in a SAFe® transformation have POs and Scrum Masters who are leading multiple remote teams. 

It can be challenging to coach Agile teams remotely and consistently on the Agile Manifesto and SAFe principles and values, such as Business people and developers must work together daily throughout the project or Program Execution. Often during these transitions, some companies expect an employee to be a part-time PO in addition to his/her day job.

Many times I have had Product Owners ask me to help supervisors understand the time commitment involved with the role. One way is to describe what a typical PO does each day. In this post, I’ve created a list of what a PO does on a daily basis. This list is not exhaustive, nor is it in any specific order:

  • Attends the team’s daily stand-up meeting to understand the team’s progress and impediments toward the Iteration goals.
  • Capture customer requirements and ideas by writing (or helping others write) stories and Enablers.
  • Continuously accepts or rejects completed stories and Enablers. 
  • Is available to the team each day to answer questions and clarify stories.
  • Works with the System Architect to ensure Enablers are properly prioritized so as not to mortgage the future of the architecture.
  • Verifies that stories are in the proper format, contain valid confirmation (aka acceptance criteria), and are in line with the Program vision and scope. This includes any necessary design details, business rules, NFRs, etc.
  • Ensures that the team is aligned to the PI Objectives, and Iteration goals are clearly defined and communicated.
  • Helps remove or escalate obstacles to Product Management.
  • Makes sure that the Agile team has a direct connection with the business through story development and the Iteration review.
  • Meets regularly with Product Management (e.g. PO Sync) to keep stakeholders informed on how much incremental value has been generated.

In addition to that, on a cadence, POs:

  • Participate in the Iteration retrospective event.
  • Present the stories and Enablers during Iteration Planning.
  • Meet with the team each week to refine the Team Backlog.
  • Work with the team to decompose stories and Enablers into small increments. Ideally something that can be completed every two to three days.
  • Prioritize and update the Team Backlog.
  • Work with the team to create and commit to Iteration goals.
  • Collaborate with team members to form PI Objectives.
  • Help identify dependencies with other teams during PI Planning.
  • Meet with Product Management and stakeholders regularly to field questions and inform them of any updates or changes to scope.
  • Conduct the Iteration review with the team and participate in the System Demo to demonstrate the incremental functionality to the Agile Release Train and stakeholders.

In your context, look at all the activities that your POs are engaged in and consider whether it’s realistic for a part-time PO to do them all. If it’s not, speak to your part-time POs and have them present this data to their managers or as an issue during your Inspect & Adapt workshop.

To learn more on the PO role within SAFe, read this article.

About Joe Vallone

Joe Vallone, SPCT, SAFe Fellow, is an experienced Agile trainer who has helped coach several large-scale Agile transitions at Zynga, Apple, Microsoft, VCE, Nokia, AT&T, and American Airlines. He’s also an effective leader and speaker with more than 20 years of software development and management experience. As a change agent, Joe is passionate about teaching and coaching organizations to reach their full potential by embracing Agile values and Lean thinking.

View all posts by Joe Vallone

Share:

Back to: All Blog Posts

Next: We Did It! Our Very First, Fully Remote, Distributed PI Planning.