Yeret Agility's Blog

What's In The Way of Your AI Traction?

Yuval Yeret — Thu, 09 Apr 2026 00:00:00 GMT

## Building With AI - Dream vs Reality Have you tried coding with AI yet? It can be an exhilarating experience. It SHOULD be an even greater experience when you're at work. The tools are paid for. There are peers who are learning and exploring with you. Maybe there's even AI training and enablement in place. But what I hear from more and more practitioners and their leaders is disappointment and frustration at what AI coding inside the organization REALLY feels like. What's going on? What's making it so hard to get AI traction in an organizational context? And what could you do to unleash the potential of "Building with AI" inside your company? ## Give Them AI And Watch Them Build "We've given everyone Claude Code/Cowork (or Codex, Or Gemini CLI). Now we're waiting for the magic to emerge." That's a common story I hear from leaders who are trying to figure out how to take AI from "Literacy" and "Activity" to "Strategy" and "Impact" The thinking is that once smart people have access to the transformational capabilities of GenAI, especially the latest versions of it that can go beyond augmenting your thinking to doing some actual work on its own, they will start to imagine what's possible and find high impact use cases. ## The Reality of Give Them AI There are a couple of problems these leaders are currently seeing, though: - Finding these use cases requires curiosity, tinkering, courage. These attributes aren't evenly distributed across the company. - Even people who are curious risk-takers seem to be afraid to experiment - Many people seem like they're deer in the headlights stuck between the fear of being replaced by AI and the fear of using AI to cut the branch they're sitting on (sorry for the metaphor mixup - AI would never go for that ;-) - When people don't know what to focus on, they might come up with AI use cases that don't move the needle. Worst case scenario they make an improvement that actually piles more work on other people. (For example - generating more code and features, when the bottleneck is training your customers) - High impact often requires coordination between people, since it spans across functions. None of these are AI problems. They are all human nature and company culture problems. AI is just very good at exposing how effective you really are as an organization at developing/evolving. ## The Reality of Project Work Before AI A lot of leaders were already feeling the pain before AI: - People are buried in their day to day responsibilities - and have little capacity for extra "projects" - Too many of these projects who all hit the same group of people - So projects are often late, despite everyone working hard. - Project management is focused on activity - and even "successful projects" often don't deliver an impact. - People are told exactly what to do - Sponsors ask for a specific solution - which has this tendency to extinguish creativity and exploration, with the side effect that sometimes the predefined solution isn't the right approach. ## What Happens When You Throw AI Into The Mix In order to deliver AI impact we need to improve our ability to deliver value with projects. Yes, by giving people AI there's the potential that they'll improve their personal productivity. But most interesting organizational "alpha" will require more than individual productivity improvement. It requires a strong capability for the organization to develop/evolve itself. Otherwise your AI projects/initiatives will hit the same roadblocks. Lots of activity. Little Traction. Little Impact. ## A Better Approach To Projects When you look at companies that manage to improve their project traction and impact, you often see several major shifts: - From Activity to Flow - From Starting to Focusing and Finishing - From Scope to Outcomes - Instead of fixing the solution, aligning around the intent and maintaining flexibility about what it will take to achieve it. - From Following a detailed plan to adaptive planning - Instead of fully planning out exactly what everyone needs to do when, planning a little bit, doing it, sensing and adjusting. continuously. until achieving the goal. These shifts come from the product/software development world where we've been tackling complex projects with high degress of uncertainty on what to build, how to build it, and whether it will even be useful, forever. Product/software development organizations have been shifting from project thinking to flow and product thinking. They've been leveraging more focused, iterative and adaptive ways of working (dare I say more agile?) ## Treat Your AI Projects as Products If you think about your AI projects - they look a lot like this. Even if they're not about your product, and don't live inside your product/engineering/IT organization - they are still rife with uncertainty and complexity about Why, What and How. Which is why when you look at case studies of companies who are getting better traction with their AI investments, you can see flow and product thinking at play: - Focusing on the investments/initiatives that really matter. - Acknowledging investments are bets and emphasizing learning/discovery before doubling down - Assigning directly responsible individuals who own an outcome - and have flexibility about the solution - Steering based on traction on leading indicators and early feedback loops - Creating empowered pods that can run with an idea with as little friction and dependencies as possible. AI Vibe Coding is useless and frustrating when its bound by the constraints of the wrong ecosystem. It is exhilirating and high-impact when unleashed by an organizational operating system that's optimized for "building with AI"

What's In The Way of Your AI Traction?

Yuval Yeret — Thu, 09 Apr 2026 00:00:00 GMT

## Give Them AI And Watch Them Build "We've given everyone Claude Code/Cowork (or Codex, Or Gemini CLI). Now we're waiting for the magic to emerge." That's a common story I hear from leaders who are trying to figure out how to take AI from "Literacy" and "Activity" to "Strategy" and "Impact" The thinking is that once smart people have access to the transformational capabilities of GenAI, especially the latest versions of it that can go beyond augmenting your thinking to doing some actual work on its own, they will start to imagine what's possible and find high impact use cases. ## The Reality of Give Them AI There are a couple of problems these leaders are currently seeing, though: - Finding these use cases requires curiosity, tinkering, courage. These attributes aren't evenly distributed across the company. - Even people who are curious risk-takers seem to be afraid to experiment - Many people seem like they're deer in the headlights stuck between the fear of being replaced by AI and the fear of using AI to cut the branch they're sitting on (sorry for the metaphor mixup - AI would never go for that ;-) - When people don't know what to focus on, they might come up with AI use cases that don't move the needle. Worst case scenario they make an improvement that actually piles more work on other people. (For example - generating more code and features, when the bottleneck is training your customers) - High impact often requires coordination between people, since it spans across functions. None of these are AI problems. They are all human nature and company culture problems. AI is just very good at exposing how effective you really are as an organization at developing/evolving. ## The Reality of Project Work Before AI A lot of leaders were already feeling the pain before AI: - People are buried in their day to day responsibilities - and have little capacity for extra "projects" - Too many of these projects who all hit the same group of people - So projects are often late, despite everyone working hard. - Project management is focused on activity - and even "successful projects" often don't deliver an impact. - People are told exactly what to do - Sponsors ask for a specific solution - which has this tendency to extinguish creativity and exploration, with the side effect that sometimes the predefined solution isn't the right approach. ## What Happens When You Throw AI Into The Mix In order to deliver AI impact we need to improve our ability to deliver value with projects. Yes, by giving people AI there's the potential that they'll improve their personal productivity. But most interesting organizational "alpha" will require more than individual productivity improvement. It requires a strong capability for the organization to develop/evolve itself. Otherwise your AI projects/initiatives will hit the same roadblocks. Lots of activity. Little Traction. Little Impact. ## A Better Approach To Projects When you look at companies that manage to improve their project traction and impact, you often see several major shifts: - From Activity to Flow - From Starting to Focusing and Finishing - From Scope to Outcomes - Instead of fixing the solution, aligning around the intent and maintaining flexibility about what it will take to achieve it. - From Following a detailed plan to adaptive planning - Instead of fully planning out exactly what everyone needs to do when, planning a little bit, doing it, sensing and adjusting. continuously. until achieving the goal. These shifts come from the product/software development world where we've been tackling complex projects with high degress of uncertainty on what to build, how to build it, and whether it will even be useful, forever. Product/software development organizations have been shifting from project thinking to flow and product thinking. They've been leveraging more focused, iterative and adaptive ways of working (dare I say more agile?) ## Treat Your AI Projects as Products If you think about your AI projects - they look a lot like this. Even if they're not about your product, and don't live inside your product/engineering/IT organization - they are still rife with uncertainty and complexity about Why, What and How. Which is why when you look at case studies of companies who are getting better traction with their AI investments, you can see flow and product thinking at play: - Focusing on the investments/initiatives that really matter. - Acknowledging investments are bets and emphasizing learning/discovery before doubling down - Assigning directly responsible individuals who own an outcome - and have flexibility about the solution - Steering based on traction on leading indicators and early feedback loops - Creating empowered pods that can run with an idea with as little friction and dependencies as possible. AI Vibe Coding is useless and frustrating when its bound by the constraints of the wrong ecosystem. It is exhilirating and high-impact when unleashed by an organizational operating system that's optimized for "building with AI"

Product Ownership Topology: The Difference Between Flow and Theater

Yuval Yeret — Mon, 30 Mar 2026 00:00:00 GMT

This article pulls together the core ideas from my recent mini-series on product ownership topology. I was recently with a client building a fairly complex mix of hardware and software. They had a platform team serving five internal product lines, a "Product Owner" for that platform team, and Product Managers for each of the lines. On paper, ownership looked covered. In practice, every serious prioritization conversation stalled out. Nobody around that platform team really had the standing to make the hard tradeoffs, so the calls kept drifting upward to the CTO. The team itself lurched from urgent request to urgent request and finished very little. I see versions of this all the time. The problem usually isn't lack of talent or commitment. It is that companies confuse job titles with organizational standing. If you're leading product in a growing company, this is one of those structural choices that ends up shaping far more than people expect. When ownership is set up well, work tends to flow. When it isn't, you feel it everywhere: prioritization turns into negotiation, escalations become routine, and teams spend a lot of energy managing requests instead of finishing meaningful work. ## Product ownership is not a title. It is the authority to make tradeoffs. Here's the test I like to use: **Who around this team can say "no" to a meaningful request and have it stick?** If the answer is fuzzy, conditional, or political, you probably don't have real product ownership. You have some version of a proxy, a queue manager, or someone carrying the role name without the decision rights that are supposed to come with it. That is one of the fastest roads to [Agile Theater](/blog/the-agile-theater/). The ceremonies are there. The tickets are there. The ownership isn't. ## The one-team trap: two titles, one product, zero clarity This often starts innocently. A growing company decides to "do Scrum," and somebody suggests a clean split: the Product Manager will focus on strategy while the Product Owner will work closely with the team. It sounds tidy. But very often what this creates is a proxy Product Owner. That person becomes the relay station between the team and the person who actually owns the decisions. They refine backlog items, answer some day-to-day questions, and run ceremonies. But when the team needs a real tradeoff, people look past them to the Product Manager, founder, or executive sponsor. At that point, decision latency goes up almost immediately. The team learns where the real authority sits and starts routing around the PO. You end up with more coordination and less ownership. For one team working on one product, my default is that one person should own the outcome. That doesn't mean they need to write every Jira ticket. It means they need enough connection to the team and enough authority in the organization to make actual calls. If your Product Manager is "too busy" to engage with the team, the answer usually isn't to add another ownership layer. More often, it is a sign that your Product Manager is being used as a roadmap broadcaster, stakeholder shield, or internal salesperson instead of a product leader. ## Platform teams get into trouble when nobody can say no Platform teams are where this issue becomes impossible to ignore. A platform often serves multiple internal products, so leaders end up treating it like a shared technical service instead of a product. Then they wonder why the team is drowning in competing requests. Here's the question I usually ask: **If this platform team stopped shipping for a quarter, would the business feel it?** If the answer is yes, then this isn't just a service desk with better tooling. It is a strategic bet, and it needs product leadership with enough standing to disappoint important people when necessary. That doesn't always mean a full-time senior Product Manager sitting with the team every day. But it does mean somebody credible and empowered needs to own the hard tradeoffs around investment and priorities for that platform. What usually doesn't work is giving a junior engineer or analyst the PO title and expecting them to negotiate with a VP Sales, a GM, and several product leaders with conflicting priorities. That isn't empowerment. It's a polite way to manufacture escalation. In situations like this, one pragmatic move is to connect platform ownership directly to the leader who owns the broader portfolio or product line. They don't need to micromanage the backlog. They do need to own the "not this quarter." Once that part is clear, the team can stop pretending every request is top priority. ## Scaling across multiple teams: don't start with the org chart As companies grow, they often copy and paste ownership roles team by team. One team, one Product Owner. It looks neat on the org chart. The problem is that products don't scale according to org chart symmetry. Product ownership works when a team can deliver meaningful value with enough independence to learn, decide, and improve. If the team mostly owns a layer, a component, or a specialist function that can't really move customer or business outcomes on its own, giving that team a Product Owner often creates more coordination overhead than value. Now you have more people representing partial interests in a system that still needs constant cross-team negotiation. That's not scaling. That's full gas in neutral. This is why topology matters so much. When I worked with Gillette on the [Exfoliating Razor](https://gillette.com/en-us/products/gillette-labs/exfoliating-bar-razor-by-gillette), the work wasn't split into neat software buckets. The meaningful questions were around product problems and choices like the shave experience, the ergonomics, and the viability of the overall bet. Those could move with a decent level of independence while still connecting to one product story. That is the kind of context where separate product leaders can actually help. If your teams are organized mostly around frontend, backend, or specialist components, slapping a Product Owner on each one rarely fixes anything. Usually it just hides the deeper issue, which is that the topology itself is fighting flow. ## A better starting question If you're trying to improve product ownership, I wouldn't start with "how many Product Owners do we need?" I'd start here: - What does this team really own? - Can it deliver value with some meaningful independence? - Who has the standing to say no on behalf of this team? - Where do hard tradeoffs get made today? - Which escalations are symptoms of missing ownership rather than bad people or bad process? Those questions usually surface the real problem much faster than a role-definition workshop does. ## If your founders or execs keep getting pulled into feature calls, your ownership model is leaking A few signs I see again and again: - prioritization meetings end in stalemate - platform teams serve everyone and satisfy nobody - the "PO" runs the backlog but not the decisions - stakeholders keep bypassing the team and going to senior leaders - every important tradeoff turns into an escalation When that happens, the problem usually isn't that people need better backlog hygiene. The problem is that your decision-making topology is leaking. You've installed the rituals, but you haven't fixed the flow of authority. ## Where to start Pick one team that feels stuck. Map the work it actually owns, the dependencies it can't escape, and the decisions it is allowed to make without escalation. Then ask the uncomfortable question: **Does the person called the Product Owner actually own anything that matters?** If the answer is no, I wouldn't start by rewriting the role description. I'd start by fixing the topology around the team. ## Frequently Asked Questions **Do I always need one person to be both Product Manager and Product Owner?** No. But for a single team working on a single product, splitting those responsibilities often creates a proxy ownership problem unless the decision rights are crystal clear and the two people operate as one. **Can a platform team have real product ownership even if its users are internal?** Absolutely. If the platform is strategically important, has real customers inside the company, and requires tradeoffs about outcomes and investment, treat it like a product. **What is the quickest diagnostic for fake ownership?** Look at who says no when priorities collide. If the person with the PO title cannot make that call stick, you likely have fake ownership. If this is hitting close to home, [let's talk](/work-with-me). I help leadership teams sort out where ownership is real, where it's theater, and what structural changes are actually worth making.

Portfolio WIP — It's Not About Limits

Yuval Yeret — Thu, 19 Mar 2026 00:00:00 GMT

## How should we limit WIP on the Portfolio Kanban? How many initiatives should we allow in each column?" Every time I introduce a portfolio Kanban system to better manage an organization's initiatives, the question of managing work in progress comes up. At the team level, WIP limits make intuitive sense. Work items are roughly right-sized. You can say "three items in progress" and it means something concrete about focus and flow. It has a direct connection to throughput. ## How is a Portfolio-level kanban system different when it comes to limiting WIP? But portfolio initiatives? One might represent five person-months of work. Another might represent five hundred. A WIP limit of "four initiatives in progress" tells you almost nothing about the actual load on the organization. What it _does_ tell you something about is **cognitive load on the leadership team.** And that's a real constraint worth managing. Every card on that portfolio board — regardless of how much organizational effort it represents — requires leadership attention. Discussion time in portfolio reviews. Steering conversations. Evidence reviews. Decision-making bandwidth. ## Limiting WIP - Not just about capacity management - also a focusing mechanism If you're a product leader, a CIO, or running a PMO that's trying to bring product thinking to the portfolio level, this is a critical distinction. You're not doing the work on these initiatives. You're providing strategic focus and governance. The bottleneck isn't team capacity — it's _your_ capacity to meaningfully steer. So the question isn't "what's our WIP limit?" The question is: **How many strategic bets can this leadership team actually pay attention to?** How many initiative owners do you have who can think holistically about a cross-product bet? How many discovery efforts can you run with real attention? Is the same person juggling five strategic initiatives and doing justice to none of them? ## Reframing from activity to intent - From Limiting to Reducing WIP I'll go a step further. I actually have a problem with how WIP limits are typically framed. "Limit WIP" is an activity. **Reducing work in process is the outcome.** A number in a column header is one technique. But at the portfolio level, the better technique is honest conversation about what you can actually steer — and what you should push down to empowered product teams instead. ## How should we approach managing work in process on a portfolio kanban? **Reduce, don't limit.** The most useful portfolio WIP question isn't "how many should we allow?" It's: _what would need to be true for us to NOT manage this initiative at the portfolio level?_ That question is what starts to flip the pyramid — pushing decisions and ownership closer to the teams who can actually move fast on them. **Manage your attention, not just the organization's throughput.** The portfolio Kanban manages the focus of the leadership team. Most of the actual work across the organization isn't managed at this level — or shouldn't be. When you set WIP constraints here, you're protecting leadership bandwidth, not throttling teams. That reframe changes the conversation entirely. **Let the board create the aha moment.** The most powerful WIP reduction I've seen didn't come from a policy. It came from a leadership team looking at their portfolio board for the first time and asking two questions: _How are we doing so many things?_ And: _Do we really need to manage all of these?_ That second question is where the real shift starts. Because once leaders start to think about what they can safely push down — once they start defining guardrails that make it comfortable to let teams run — you've started the transition from centralized portfolio management to something much more product-oriented. The irony is that the PMO instinct — let's get everything visible and manage it tightly — is actually the right _first_ step. You need to see the swamp before you can shape it into a river. But the _next_ step isn't tighter management. It's deciding what deserves your strategic attention and what deserves your trust. The key question therefore is _How many of the cards on your portfolio board actually need to be there?_

Agility is about efficiently seeking alpha

Yuval Yeret — Mon, 09 Mar 2026 00:00:00 GMT

Cycling with my son to school is one of my favorite morning rituals. Beyond the quick ride to school, I usually turn it into a longer loop with a couple of neighborhood hills. Nothing too aggressive. Just enough fresh air and headspace to think. One recent ride led me to a thought that has been rattling around in my head since: **Agility is about efficiently seeking alpha.** That probably requires some explanation. In investing, **alpha** is excess return. In the world of product development and business initiatives more broadly, I think of alpha as the excess return from developing new capabilities. That could be a new product, a feature, a new internal capability, a new go-to-market motion, a better pricing model, whatever. If your organization is doing anything beyond pure keep-the-lights-on work, you're probably already seeking alpha. The question is whether you're doing it in a smart way or an expensive way. Here's what I mean: Agility doesn't magically create alpha. What it does is help you **seek alpha more efficiently**. It helps you learn faster and cheaper whether an idea is worth pursuing, reshaping, or killing. That might sound subtle, but I think it's actually the whole game. Speculative investing became a lot easier once transaction costs dropped. You can place a bet, see what happens, and adjust without paying huge tolls on every move. Speculative investing in products, capabilities, and strategic initiatives becomes easier when the cost of learning drops. When you can test earlier, integrate faster, get feedback sooner, and change direction without a bureaucratic drama festival, you can place more meaningful bets and manage them better. That is a big part of what agility is about. When I shared this thought on LinkedIn, Ed Kless made a good point. Why "efficiently" and not "effectively"? He's right that if you do something ineffective more efficiently, you can make the situation worse faster. I'm using **efficiently** on purpose. At the level of a single product idea or feature, effectiveness matters more. If you're building the wrong thing, doing it faster is not inherently useful. But at the portfolio level, and certainly at the operating-system level, efficiency matters a lot because it changes the economics of search. If we can seek alpha more efficiently, the overall system can become more effective because we can: - place more bets - get evidence sooner - sift weak ideas out earlier - invest more in the ideas that are actually showing promise And to be clear, good agility should improve effectiveness as well, because it isn't just about speed. It is also about empiricism. It helps you select and steer better, not just move faster. This is one reason I keep thinking about EOS and similar business operating systems. EOS is great at bringing discipline and structure when a founder is stretched too thin. Same for other operating systems and management frameworks. They can dramatically improve alignment, accountability, and traction. But more and more leadership teams I talk to are asking a deeper question: **Where's the entrepreneurial in the operating system?** Is the system helping us seek organizational alpha? Is it helping us navigate hard shifts that require cross-functional collaboration, fast feedback loops, and evidence-informed steering? Or is it mostly helping us track commitments and run cleaner meetings? The leadership team of a brewery collective I'm working with is wrestling with exactly this. They're leveraging techniques and mindsets from the product/agility world to scale entrepreneurship across the organization. What seems to matter most is not adding more project management. It is replacing project management with: - outcome orientation - evidence-informed efficient experimentation - faster cycles - cross-functional collaboration around real bets That's the entrepreneurial upgrade. You can see a similar shift right now with AI vibe coding. It doesn't guarantee a good business idea. What it does is make it much cheaper to test one. That changes the game. It makes bootstrapping viable in places where previously you'd need a bigger budget, a bigger team, or more investor patience just to get to first evidence. Agility plays a similar role inside organizations. It doesn't guarantee insight. It doesn't guarantee product-market fit. It doesn't guarantee strategic judgment. What it can do is reduce the cost of finding out whether you're onto something. And when you can do that repeatedly, cross-functionally, and without excessive friction, you're in a much better position to create real alpha. So when I say agility is about efficiently seeking alpha, I don't mean "go faster no matter what." I mean build an operating system that makes it cheaper and easier to: - pursue promising bets - inspect reality early - adapt based on evidence - stop protecting weak ideas just because they're already on the plan That's a much more useful definition of agility than ceremonies, velocity, or whether teams are following the script. That's also where I think the next generation of operating systems is headed. Not abandoning EOS, OKRs, or other systems. Upgrading them with stronger outcome orientation, more empiricism, and better support for entrepreneurial search. That's the thought, anyway. ## Curious whether this framing resonates with you. _Moving from agile theater to real business agility takes more than a framework — it takes a deliberate operating model shift. [Explore Business Agility advisory](/work-with-me) or [let's talk](/work-with-me)._

In the Spotlight - Building and Operating Your Revenue Machine

Yuval Yeret — Fri, 06 Mar 2026 00:00:00 GMT

Most revenue leaders I work with are not struggling with effort. They are struggling with leverage. There is plenty of activity: pipeline reviews, enablement decks, tool rollouts, process updates. But for many organizations, the system keeps producing the same bottlenecks. Forecasts stay noisy. Hand-offs stay brittle. Adoption of "new and improved" ways of working fades after the first push. That was the core topic in my recent conversation with Roi Carmel on _In the Spotlight_: if you want durable GTM performance, you need to do two jobs at once: 1. Operate today's revenue machine. 2. Build the next version of the machine while you run it. ## Why "rollout thinking" keeps failing in GTM Many change initiatives fail quietly because they are designed as one-time deployments. New CRM workflow. New qualification framework. New operating cadence. Then leadership expects immediate adoption and measurable impact. In reality, GTM systems are living systems. Buyer behavior shifts. Team composition changes. New channels appear. AI changes how teams work week to week. If the change model is static while the environment is dynamic, ROI will usually disappoint. The pattern I see repeatedly is this: organizations treat operating model change as a project to complete, not a capability to cultivate. ## Key Insights > "In parallel to building the product, you need to build the organization that is building the product." For revenue teams, that means building better decision loops, better cross-functional coordination, and better adaptation habits, not only better plans. > "People don't really like being inflicted change upon. They like to be part of the process." Adoption is not communication. Adoption is co-creation. Teams are far more likely to sustain behavior change when they help shape it. > "If people fail, then that's a failure of the system." When execution is inconsistent, start with system design before blaming individuals. Usually there is a policy, interface, incentive, or workload issue hiding under the symptoms. ## A practical operating approach If you lead sales, marketing, RevOps, or product marketing, here is a pragmatic pattern: 1. Pick one business-critical outcome (for example: forecast reliability, win-rate in a segment, or cycle-time to qualified pipeline). 2. Map the current system that produces this outcome across functions. 3. Run small experiments in the operating model, not just in messaging or tactics. 4. Review both business outcomes and adoption signals. 5. Keep what works, adapt what does not, and repeat. This is the same logic strong product teams use: short cycles, evidence over opinions, and continuous learning in context. Watch the full conversation here: [In the Spotlight - with Yuval Yeret](https://www.youtube.com/watch?v=UZNXwQ9UGsw) ## Keep exploring in the insights library If this topic resonates, these pieces go deeper: - [AI isn't the problem - your operating system is](/blog/ai-isnt-the-problem-your-operating-system-is) - [When Traction Becomes Friction](/blog/when-traction-becomes-friction-how-to-upgrade-your-operating-system-for-speed-and-uncertainty) ## A few other questions that often come up in conversations about applying continuous learning/adaptation to the revenue/GTM machine ### Is this mainly relevant for large enterprises? Not necessarily. The pattern appears in scaleups, mid-market firms, and enterprise contexts. The size changes; the operating-system dynamics are similar. At the extreme, even soloists like me have to run the revenue machine in parallel to evolving it. ### Should RevOps lead this alone? RevOps is central, but not sufficient alone. Durable change needs shared ownership across sales leadership, marketing, product marketing, and supporting functions. That's one of the key insights - change participants need to feel and show up as players, not pawns, if you want the change to stick and to really serve the needs of the organization. ### How fast should we expect results? ## Well, this is an interesting one. On one hand participatory evolutionary change might seem slower because you have to involve more people, and plan for iteration rather than one big bang. On the other hand, the right plan could leverage this iterative incremental nature to show quick progress and value along the way. Ideally you can front load value, seeing much faster results, and even trim the tail - skipping some aspects of the change that you initially planned for but are realizing aren't needed after trying some things out. _Moving from agile theater to real business agility takes more than a framework — it takes a deliberate operating model shift. [Explore Business Agility advisory](/work-with-me) or [let's talk](/work-with-me)._

Podcast Deep Dive: AI Strategy and the Operating System Mismatch (with Dave West)

Yuval Yeret — Thu, 26 Feb 2026 00:00:00 GMT

In a recent episode of the Scrum.org podcast, I sat down with CEO Dave West to discuss why so many organizations are struggling to turn their AI investments into business impact. While we've previously discussed how your Operating System can be a bottleneck for AI, this conversation focused specifically on the _mechanics_ of how AI adoption is shifting the boundaries of traditional IT. ## The High Failure Rate of AI Projects Dave highlighted a startling figure: **95% of AI projects fail to deliver meaningful value.** But as we explored the "why" behind this number, a pattern emerged. These failures rarely stem from the technology itself. Instead, the failure happens when organizations try to "project-manage" a complex, emergent technology with a 20th-century mindset. > "The key for me, what I see where people are finding gold using AI... is when they use product techniques, whether they call it product or not." ## Beyond the IT Boundary One of the most profound insights from our discussion was that **AI adoption challenges now originate outside traditional IT.** We're seeing sales, marketing, and legal departments leading AI initiatives without the necessary operating system to support the uncertainty of high-potential developmental work. ### Context is the New Training Data We discussed the concept of "Context Development." Just as a product defines its scope and purpose, an organization must provide AI with consistent boundaries and relevant information to be effective. This is why some suggest that _Context is the new Code_: the performance of GenAI depends less on how you code the interface and more on the quality and specificity of the context—data, constraints, user persona—you provide it. ### Key Takeaways for Leaders: 1. **Differentiate Work Types:** Don't treat operational optimization (stable work) the same as innovation (complex work). AI fits best into an agile, product-oriented mindset. 2. **Strategy Alignment (OKRs):** Use OKRs to ground AI initiatives in real business strategy rather than technology for technology's sake. 3. **Continuous Adaptation:** Your OS must be capable of sensing, responding, inspecting, and adapting in real-time. Even a traditional PMO can adapt to this reality, provided they shift from "schedule policing" to "enabling evidence-based governance" focused on leading indicators of value. --- _Listen to the full episode on Scrum.org: [AI and the Implications for your Organization’s Operating System](https://www.scrum.org/resources/ai-and-implications-your-organizations-operating-system)._

WIP Limits in Scrum with Kanban: What, When, Who, and How

Yuval Yeret — Fri, 23 Jan 2026 00:00:00 GMT

One of the key Kanban practices is Limiting Work in Progress. If you want to be pedantic, what this practice actually aims to do is reduce and stabilize Work in Progress. This improves flow, provides predictability, and is actually even more important for creating a pull-based Kanban system than visualizing your workflow using a Kanban board. I worked with several clients who limited their WIP but didn't use Kanban boards. One could argue that this practice deserves to be first on the Kanban practices list, ahead of Visualization. Anyhow, when a Scrum Team implements Kanban, they should definitely figure out how to limit and reduce their Work in Progress. This is a key part of their definition of "Workflow". Now, a question comes up: ## Who should define the WIP Limit? Let's assume the team is using Kanban to improve Sprint flow by visualizing and managing the Sprint Backlog. The Sprint Backlog is owned by the Developers, so it would make sense for them to own their workflow, including the WIP limits in this case. What if the team is using Kanban from a more holistic perspective, starting with the Product Backlog and including refinement work? In this case, the Scrum Team would own the workflow and therefore need to discuss WIP limits. While there are specific accountabilities on the Scrum Team, most importantly, the Scrum Team is accountable for working effectively to deliver value. ## Should WIP limits be changed to deal with mid-sprint high-priority work? Now let's assume a team is mid-Sprint, and there's an important, valuable item the Product Owner wants to add to the Sprint Backlog. It is aligned with the Sprint Goal. The team is currently at its WIP Limit. Could they add this item? Should they? What needs to happen to the WIP limit? My take on this is that, first of all, a decision needs to be made whether to pull this item into the Sprint Backlog. This discussion isn't related to Kanban at all. It is a core Scrum question, and the answer is that it is up to the team to agree to pull a new item into the Sprint Backlog. The Sprint Goal can be used to assess how aligned this item is with the current focus. If the item is pulled into the Sprint Backlog, the Developers need to determine whether they can start it right away. This depends on the WIP limits and the current WIP. If the team is at their WIP limit, they shouldn't pull in that new item until some room frees up. If their backlog items are pretty small, an empty WIP slot will free up pretty quickly. If items are big, it can take a while. In general, I don't recommend changing WIP limits on a whim just because there's a need during the Sprint. I'd rather [see an exception and discussion](/blog/the-scrum-sprint-commitmentforecast-as-an-expectation) rather than hide the problem under a policy change. Note the exception, maybe even fail to create a really Done Increment, and inspect exceptions later in the Retrospective. ## How should Scrum teams limit their WIP? One last thing to note about limiting WIP is that, while we typically talk about it as per-lane constraints in your workflow, this is just one specific way to do it. You could limit the amount of work in progress per person, for the entire team throughout their workflow, or actually limit WIP by time. For example, "we won't work on more than 10 items this week". That sounds familiar: #SprintForecast. A good starting point is to keep it simple with conservative limits per workflow stage. Observe flow for a couple of Sprints, and then adapt based on aging work, throughput, and bottlenecks. ## Some more real-world scenarios Limiting and reducing WIP is one principle where the real-world application requires nuance. See [WIP Limit Anecdotes from Scrum with Kanban Teams](/blog/limiting-work-in-progress-wip-some-anecdotes-worth-thinking-about-when-using-kanban-with-scrum/) for some more examples from the trenches. Managing and reducing WIP is also a highly fractal principle. Applying it as part of [Portfolio Agility](/work-with-me/portfolio-agility/) can be a great catalyst for starting or [Fixing Your Agility](/work-with-me/fixing-your-agility/). --- _Figuring out when and how to limit WIP in a way that accelerates sustainable value delivery is a key aspect of my [advisory services](/work-with-me/). Whether it's at the team, group, or portfolio level, flow is my favorite transformation hack._

Is it a Product Operating Model? Or is it Stage-gates?

Yuval Yeret — Tue, 20 Jan 2026 00:00:00 GMT

Navigating the opportunity-rich environment of the AI age, when your company is considering dozens of "finding AI gold" initiatives, requires discipline and product-orientation. I'm working with a PMO leader to develop a product-oriented portfolio management approach in an organization with deep roots in pharma, chemistry, and hardware development. Meaning an ongoing clash between stage gates and agility/product-orientation. I'm recalling an exercise we included in the Scrum.org Professional Scrum w/ Kanban. The "Is it Waterfall? Is it Kanban?" exercise is one of my favorites because it explores the folly of extreme views on this. Being product-oriented and iterative doesn't preclude the use of stage gates. It precludes big-batch stage gates that lock in too much up front. It actually benefits from the right sort of stage gates, those that focus on flushing out risks/leap-of-faith assumptions. That enables, and even forces, explicit choice between discovery (tracer bullets) and delivery (cannon balls) depending on the risk profile. Curious: how are you thinking about the role and evolution of stage gates in the AI age? If you are navigating this tension right now, see [Figure Out Your Product Operating Model Strategy](/work-with-me/figure-out-your-product-operating-model-strategy/) and [Portfolio Agility](/work-with-me/portfolio-agility/).

How ARAS Software Is Agile about How They Scale Agile

Yuval Yeret — Wed, 17 Dec 2025 00:00:00 GMT

You scaled your team to 60+ engineers. You installed the "industry standard" frameworks to keep everyone aligned. For a while, it worked. But lately, it feels different. PI Planning has become a ritual people dread. Innovation cycles have turned into "dead zones." Your teams are spending more time managing the process than shipping code. You’re starting to become the incumbents you started your business to disrupt. Here is how one high-growth PLM leader, ARAS Software, navigated the scaling journey with agility. Specifically, you'll learn how Aras continuously accelerated engineering productivity and throughput by making the right scaling choices at key points on their growth journey - introducing SAFe for initial scaling, and evolving beyond classic SAFe mechanisms when they outgrew them. This isn't a "polished" shiny conference case study. It's a raw look at what's happening in the trenches of mid-market scaleups. https://youtu.be/QK\_Yl46tQt4 [https://api.substack.com/feed/podcast/1195288.rss](https://api.substack.com/feed/podcast/1195288.rss) ## Find the Scaling w/ Agility Podcast on your favorite Podcast Player: If your scaling motion is becoming process-heavy and value-light, [Fixing Your Agility](/work-with-me/fixing-your-agility/) and [Portfolio Agility](/work-with-me/portfolio-agility/) are the two most relevant starting points.

When Traction Becomes Friction: How to Upgrade Your Operating System for Speed and Uncertainty

Yuval Yeret — Tue, 25 Nov 2025 00:00:00 GMT

**Why the "professional management" playbook needs a dose of empiricism.** Many leaders install a Business Operating System (BOS)—such as EOS, Scaling Up, or OKRs — and achieve significant improvements in execution discipline and traction across their organization. They set annual goals, break them into quarterly "Rocks," and execute on them. Many leaders are discovering that there's an essential nuance to what this execution looks like. Many of the goals they're pursuing are full of complexity, uncertainty, volatility and ambiguity. Following the plan can lead to a situation where "the surgery succeeded, and the patient died". The project is "successful," but it didn't "move the needle". **So what's the alternative to following the plan? Responding to Change. This is what we mean by agility:** aligning on a strategic goal and executing it with the ability to sense what is really going on and respond quickly. The earlier you sense, the faster you respond, the less energy and time you waste going down the wrong path. It’s almost like a cheat code to tilt the odds in your favor. If a BOS provides the **discipline** to march, Agility delivers the **intelligence** to know if you’re marching off a cliff. Here is how to upgrade your BOS from a static reporting tool to a dynamic innovation engine. ### 1\. From "Accountability" to "Empiricism." A BOS effectively solves the "who will do what, by when" problem. This creates accountability. But in complex environments—whether you are restructuring a sales channel, changing a compensation model, or mandating a return to office—_doing what you said you would do_ isn't enough if the assumption behind the task was wrong. **The Agile Upgrade:** Don't use your Weekly L10 or Management Meetings to check off tasks ("Did you send the RTO memo?"). Use them to review **evidence**. - **Traditional BOS (Output):** "I sent the 'Return to Office' policy update to the whole company." (Task Complete). - **Agile BOS (Outcome):** "We piloted 'Anchor Wednesdays' with the Finance team. Productivity remained flat, but employee NPS dropped 20 points. We should pause the wider rollout and interview the team." (Learning). This shifts the culture from **compliance** ("I did my job") to **learning** ("We tested the policy, and it needs work"). You still maintain the meeting discipline, but the content shifts from status updates to hypothesis testing. ### 2\. Treat "Rocks" as Bets, Not Contracts In many operating systems, quarterly priorities are treated as set in stone. The goal is "Green" or "Red" based on completion. This creates a perverse incentive: teams will execute a bad idea just to get a "Green" score. **The Agile Upgrade:** Frame your quarterly goals as **Hypotheses** or **Target Conditions**. - **Instead of:** "Roll out the new subscription pricing model to all clients." - **Try:** "Validate that 20% of renewals will accept the subscription uplift without churning." This allows the "How" to change while keeping the "Why" aligned. **Real-World Example: The "Recurring Revenue" Play** A typical business move is shifting a service business from one-off projects (lumpy revenue) to retainers (predictable revenue). - **The Traditional BOS Way:** The "Rock" is "Launch Retainer Model." The team spends 90 days rewriting contracts, updating the CRM, and training sales. They launch in Q2. Clients balk at the price. The quarter is wasted. - **The Agile Way:** The "Rock" is "Validate the Retainer Value Proposition." ### 3\. Organize Around Value Streams, Not Just "Seats." Standard operating systems love an Org Chart. They ask, "Do we have the right person in the right seat?" (e.g., VP of Sales, VP of Ops). But when you are trying to enter a new market or fix channel conflict, functional silos kill speed. Legal blames Sales for bad terms; Ops blames Sales for impossible delivery dates. **The Agile Upgrade:** Don't just ask "Who sits where?" Ask **"How do we deliver value to this new segment?"** You likely need a cross-functional team—what we call a **Value Stream Team**—that cuts _across_ the silos. **Real-World Example: Entering a New Market.** Let's say you acquired a generalist HVAC services company and want to attack the specialized "Medical Facilities" market. - **The Silo Way:** Marketing buys a list. Sales cold calls. Ops waits for a signed contract. When a deal finally lands, Ops realizes they lack the certifications to service a hospital. The deal dies. - **The Agile Way:** Create a "Medical Vertical Squad." ### The Bottom Line A Business Operating System is necessary. It replaces the founder's "fragile, personality-driven model" with a professional chassis. But if you stop there, you risk building a bureaucracy that is efficient at doing the wrong things. If this is your challenge, see [Create a Business-level Operating System leveraging Agility](/work-with-me/create-a-business-level-operating-system-leveraging-agility/) and [Portfolio Agility](/work-with-me/portfolio-agility/).

How to Upgrade Your Scaling SMB's Operating System Without Losing Agility

Yuval Yeret — Tue, 04 Nov 2025 00:00:00 GMT

Growth is supposed to feel like acceleration. For most companies with 50-500 employees, it feels like wading through mud. You added people, more layers, and "responsible adults." But instead of getting faster, you got slower. Predictability is down, and coordination overhead is overwhelming your top talent. I was discussing this exact problem with Dave West on the Scrum.org podcast, as part of a series focused on how agility can help small and medium-sized businesses tackle their growth challenges. We agreed: scaling doesn't have to mean slowing down, but it almost always does. It's because leaders fail to address four systemic traps. [https://api.substack.com/feed/podcast/1195288.rss](https://api.substack.com/feed/podcast/1195288.rss) Here’s the pragmatic breakdown. **1\. Your 'Founder Brain' Is Now the Bottleneck.** The skills that got you from 10 to 30 people (hustle, intuition, product-market fit) are not the skills that get you to 100 or 300 (operating as a system). Early-stage leaders who excel at building often hit a ceiling when they need to enable a multi-team organization. The system is now too complex for a single person to manage. It's time to scale up. **2\. You Optimized for Silos, Not for Value.** As you added functions—Sales, Marketing, Product, Ops—you built functional fiefdoms. Now, each department hits its own scorecard, but the _customer_ waits. You're spending more time in "alignment" meetings than on execution because value flow is breaking down at every handoff. You're optimizing locally while the system slows globally. Instead of defaulting to departments, organize around outcomes. A cross-functional "Pipeline Health" team, for instance, will consistently outperform disconnected Sales and Marketing units trying to "coordinate" via endless meetings. Your collaboration structures should reflect the flow of value, not a list of functions. ## **4\. Your Scaling Framework Became a 'Responsibility' Checklist** EOS, Scaling Up, D4X... these frameworks can be helpful. But too often organizations end up _serving the framework_ instead of making it serve _them_. You're treating "rocks" and scorecards as activity trackers, not as measures of real-world traction. All of these frameworks can benefit from a healthy dose of outcome orientation, aligned autonomy and evidence-based management.

AI Isn’t Failing — Our Operating Systems Are

Yuval Yeret — Fri, 24 Oct 2025 00:00:00 GMT

Executives keep hearing that “95 percent of AI projects fail.” The truth is uglier: it’s not the models that are failing, it’s the _management operating systems_ we're using to leverage them. **The AI/OS Mismatch:** AI is high-potential/high-uncertainty work. Managing it with 1990s waterfall thinking is why 95% of projects fail. AI needs a Product Mindset, not a Project Plan. Most organizations treat AI like a project — scope, budget, work breakdown structure, milestones. But looking for ways to leverage/operationalize AI is prime example of high potential with high uncertainty. Will this be a practical use case? Is it feasible? Viable? ![](/assets/images/blog/Scaling-Lean-Product-Management-Linkedin-Live-1.jpg) ### Why AI Adoption Often Stalls | Traditional Approach | The AI-Ready Reality | | :------------------------------ | :------------------------------------------------------------------------------------------ | | **"AI is an IT project."** | AI adoption challenges live in Sales, Marketing, and Legal. It's an _organizational_ shift. | | **"Delivering scope = Value."** | You can deliver every feature on your AI roadmap and still move zero business metrics. | | **"We need better models."** | You need better _context_. AI effectiveness is capped by how well you define the problem. | | **"Agile is for developers."** | AI requires "Agile" thinking at the leadership level: sensing, responding, and pivoting. | Managing such work like a project often results in nasty surprises - projects don't deliver on time, and even when they do, they fail to make an impact. ### How to Find "AI Gold" To find "AI Gold," you have to stop managing deliverables and start managing **outcomes**. This requires three fundamental shifts in your Operating System: 1. **Context is the New Code:** In the age of AI, _Context is the training data._ Your OS must provide clear boundaries, defined users, and specific success criteria. The smarter your context, the faster your AI learns. 2. **Bounded Learning Loops:** Instead of a 12-month "AI Roadmap," you need short "Learning Cycles." The goal is to gather _evidence_. If the evidence says "no," you pivot immediately—minimizing the cost of failure. 3. **Outcome-Driven Governance:** Traditional PMOs focus on schedule. An AI-ready OS asks "Are we moving the needle?" using Leading Indicators and OKRs. ### The Hidden Bottleneck: Your Operating System Think of how you manage strategic projects in your organization: - Crawl - It's so chaotic, it's impossible to deliver even a pretty stable project. - Sit - We deliver stable projects through professional project management and accountability (e.g. through a PMO, adopting EOS). High-potential, high-risk projects are still a crapshoot. - Walk - We can deliver high-technical/feasibility-risk projects through effective collaboration and fast feedback loops. Some of these projects provide the promised outcomes, but some of the most strategic ones don't. - Run - This is the holy grail. We are able to maximize returns and minimize investment even for high-potential high-risk investments by leveraging derisking mechanisms, whether the risk is implementation, need, or total cost of ownership. When leaders pull me in for advice, I see distinct differences between product-focused initiatives and the rest. Most organizations have learned they need to walk and run when it comes to their product/tech initiatives. But when it comes to other initiatives, even this taxonomy is foreign to most company-level PMOs and leaders. What happens when you plug AI into this environment? Companies that are working to leverage AI in their products are doing reasonably well. There's plenty to learn and do when it comes to designing, developing, and maintaining AI features, as well as leveraging AI to accelerate product development, but product/tech organizations are at least aware of what they should be aiming for. This is true when integrating AI capabilities into your internally focused products and systems as well. The challenge arises when organizations try to leverage AI beyond the boundaries of their traditional IT. It's these use cases that have high potential but often fail miserably because they're not managed properly. ### Apply Product Thinking to AI Organizations that _do_ find gold with AI borrow habits from great product teams: 1. **Start with a problem, not a technology.** Ask, “Where would we _hire_ AI to move the needle?” not “Which tool should we buy?” 2. **Work in bounded, outcome-driven loops.** Treat AI efforts like products with clear hypotheses, customers, and measures of success. 3. **Continuously develop context.** The more clarity you give teams about constraints, users, and success criteria, the smarter their experimentation becomes. Context is the real training data. At a BioTech firm I worked with, for example, scientific teams used Scrum-like loops to test how AI models could accelerate gene-therapy design. The secret wasn’t better algorithms; it was better _empiricism_ — visible hypotheses, short learning cycles, and shared evidence across disciplines. ### Upgrading the Company, Not Just the Code You don’t need to replace your entire operating system, but you do need to upgrade it for _learning speed_. Ask yourself: - Are strategic initiatives expressed as **outcomes** or **projects**? - Do our scorecards show **leading indicators** we can steer with, or lagging ones we report after the fact? - How often do we inspect and adapt our bets based on evidence, not hope? ### The Real Playbook The organizations turning AI into business impact share one discipline: _agility_. Not the capital-A flavor with ceremonies and roles, but the practice of aligning, inspecting, adapting, and flowing work toward outcomes. They learn faster, and pivot cheaper. They’ve moved from projects to products way beyond the classic boundary of the product/tech organization. AI isn’t a silver bullet. It’s a forcing function. It exposes how slowly our organizations learn. Before you invest in more models, invest in an operating system that can _think and adapt like one._ ### Summary: Upgrading Your AI Operating System - **Reframe Pilots:** If AI pilots stall despite promising models, the constraint is usually your operating model, not the technology. Reframe initiatives around outcomes and run short inspect-and-adapt cycles. - **First Step:** The most critical change is to move from project-based execution to hypothesis-driven product loops with cross-functional ownership. - **Evolving the PMO:** Traditional PMOs can still play a role, but only if they shift from schedule policing to enabling evidence-based governance and decision quality. Dive deeper in this recent Scrum Community Podcast conversation: [Why AI adoption requires an agile operating system](https://youtu.be/fGEr4Np7wdk?si=Ah0b8iCXR2ce5zrX). --- _Turning AI activity into measurable business impact is exactly the work I do with leadership teams. Explore [AI Transformation advisory](/work-with-me/ai-transformation-strategy-to-execution) or [book a Clarity Call]({{DISCOVERY_URL}}) to diagnose what is slowing your organization's AI returns._

Navigating the Product Operating Model Landscape - An Audio Series

Yuval Yeret — Fri, 17 Oct 2025 00:00:00 GMT

[](https://substack.com/@yuvalyeretagility) **Do you feel inspired by becoming an empowered product organization, but are unsure of the concrete steps to take to initiate the transformation?** ## **What You’ll Learn:** - _**Why Agile Feature Factories Fail—and What to Do About It**_ - _**Assessing Your Current Operating Model—Are You Stuck in Projects?**_ - _**Principles of Effective Product Operating Models**_ - _**When does a Product Operating Model make sense?**_ - _**Making It Real: Mapping Your Trail Toward Transformation**_ ## **This is for you if you’re:** - A Head of Product, Technology, Engineering, or Product Ops, trying to apply or scale product-led practices - Tired of theory or comprehensive perspective frameworks and hungry for real-world strategies that work - Too busy to sit down for training or even watch a video “masterclass” (Webinar in disguise…) and prefer to consume audio podcasts. - Not a fan of 6-figure, inspiring slide decks left behind by expensive consulting firms and product experts. - Trying to discern ---

What should Reviews look like in a Product Operating Model?

Yuval Yeret — Wed, 01 Oct 2025 00:00:00 GMT

Show me your Review sessions and I'll easily tell you whether you're a process theater, feature factory, or product lab. How do you switch from a feature factory to a product lab? From an organization managing projects and plans to one focused on traction towards outcomes and business impact? https://youtu.be/AifEjtiZ4rI You change the focus of your review sessions. Here's what I'm working on with a product leader who wants their organization to focus on outcomes and is trying to get product managers to think more strategically. Instead of product reviews that focus on backlogs, plans, and reviewing outputs and deliverables... We are coaching product managers to focus on the outcomes they're seeing from the work. What are the leading indicators? Do we still believe this direction makes sense? And even beyond that, what evidence are we seeing about how the product is doing? About traction towards our strategic goals? What insights can we gain from our product and business KPIs? Do you have any fresh ideas on how to move the needle towards our North Star Metrics? Are there any new metrics that matter that we should focus on? So how about you? What do YOUR Product Reviews focus on? Are there any interesting ways you've been shifting them towards Outcomes and Impact? [https://api.substack.com/feed/podcast/1195288.rss](https://api.substack.com/feed/podcast/1195288.rss) ## Find the Scaling w/ Agility Podcast on your favorite Podcast Player:

From Agile Theater Doom Loop to Strategic Agility Flywheels

Yuval Yeret — Mon, 15 Sep 2025 00:00:00 GMT

Lately, I’ve been exploring the concept of the flywheel idea. Jim Collins wrote about it years ago, but I see more leaders rediscovering it in practice. When a flywheel works, each turn makes the next one easier. Activities reinforce one another, and outcomes compound over time. The opposite is the doom loop. That’s when every step feels uphill. You spend more and more energy just to keep things moving. Eventually, leaders lose interest in the transformation, and the wheel starts to slow down. > ### 💡 Insight: Invisible Agility > > If you're still talking about 'Story Points' and 'Sprints' after 12 months, you're in the Theater phase. Real success is when leaders talk about _Cycle Time_ and _Outcomes_. If you’ve been part of a transformation—whether toward agility, alignment, or scalability—you probably know that feeling. ## What It Should Feel Like When you’re in flywheel mode: - Work flows into the next stage instead of getting stuck in hand-offs. - Each cycle gets smoother, not harder. - Each cycle produces more outcomes, not just more activity. ## Where the Doom Loop Shows Up Most stalled transformations I see are caught in this spiral. Teams are running ceremonies, leaders are paying consultants, Jira is full of “features” and “stories.” But outcomes aren’t improving. That’s Agile Theater—a doom loop disguised as progress. ## How to Switch the Momentum The way out usually isn’t more effort at the team level. It’s stepping upstream and addressing the constraint that keeps creating drag. One typical example: product agility efforts that stall because portfolio and funding processes are still legacy. Teams may be set up with backlogs and boards, but if work is still pushed down project by project, the wheel won’t spin. Portfolio-level interventions—such as leaner planning, product orientation, and flow-based funding—unlock the system. The same goes for OKRs. You can polish team OKRs forever. But if the strategy that feeds them is unclear or misaligned, you’ll stay stuck. Working at the company level is where you get leverage. ## From Doom Loop to Flywheel The difference between a doom loop and a flywheel isn’t effort. It’s leverage. Leaders who solve for the fundamental constraint create conditions where momentum builds, rather than drains. --- **Over to you:** Where have you seen a flywheel at work? And what’s the doom loop that keeps you up at night?

From Agile Theater to Product Breakthroughs: What Biotech Can Teach Us About Running Companies Like Products

Yuval Yeret — Wed, 27 Aug 2025 00:00:00 GMT

When I first started working with Dyno Therapeutics—a Boston-based biotech tackling the gene therapy delivery problem—it didn’t look that different from many scaleups I’ve seen. Brilliant scientists, tons of funding, cutting-edge ideas. But also the antipatterns that creep in with scale - silos, dependencies, and a growing sense of “process theater”. The turning point came when leaders at Dyno stopped trying to “install Agile” and instead focused on regaining and improving Dyno's agility and traction. A key unlock was a workshop where we explored the question "_What if we organized Dyno itself like a product?_" That’s essentially the story you’ll hear on the latest [Scrum.org Community Podcast](https://www.scrum.org/resources/bringing-ideas-apom-life-lab-how-dyno-uses-agile-deliver-scientific-breakthroughs) with Tyson Bertmaring (COO and Head of Stewardship) and Adrian Veres (CSO). They share how Dyno moved from handoffs and functional silos to empowered, cross-functional teams aligned to clear product goals. https://open.spotify.com/episode/6WkuOtCGgjLOnrdXSkIrov?si=nbQkayV9TGCCs1QO0mOEeA What stood out for me listening back: - They didn’t copy/paste Scrum ceremonies. They focused on **clarity of goals and continuous inspection/adaptation**. - They dared to rip off the band-aid—building scientific teams that combined lab associates, data scientists, and ML engineers around a single outcome. - They treated the **company itself like a product**, evolving its operating model with the same empiricism they applied to their science. That’s the **Agile Product Operating Model (APOM)** in action. Not Agile Theater. Not “installing a framework.” But developing your company the same way you develop products: set outcomes, test approaches, learn, adapt. I was fortunate to play a small role early in this journey, nudging the conversation away from agile mechanics towards agility and product principles. The results speak for themselves: faster innovation loops, aligned incentives, and a structure that scales with complexity instead of collapsing under it. (Tyson dives deeper into this earlier part of the journey on a [past episode](https://www.scrum.org/resources/company-spotlight-dyno-therapeutics-using-scrum-biotech)) ## 👉 If you’re wrestling with silos, coordination overhead, or transformation fatigue, I encourage you to listen to [the episode here](https://www.scrum.org/resources/bringing-ideas-apom-life-lab-how-dyno-uses-agile-deliver-scientific-breakthroughs). And then ask yourself: _are we running our org like a theater production—or like a product?_

Why Do So Many Business Transformations Flop?

Yuval Yeret — Wed, 30 Jul 2025 00:00:00 GMT

[https://api.substack.com/feed/podcast/1195288.rss](https://api.substack.com/feed/podcast/1195288.rss) ## Find the Scaling w/ Agility Podcast on your favorite Podcast Player: In this solo episode of *Scaling With Agility*, Yuval Yeret pulls back the curtain on why so many agile, digital, and business transformations, more generally, fail. Instead of doubling down on top-down mandates and theater, Yuval explores how to foster meaningful change by treating transformation as an internal market. From empowering teams to structuring change as experiments, this episode offers a different take on achieving real organizational agility for leaders tired of check-the-box change and looking to drive outcomes that stick. https://youtu.be/Cvg7kyxvILo - "You don't scale transformation by copying and pasting. You do it by treating it like a product—by validating its desirability and iterating." - "Empower teams with agency and context. Don't dictate rituals; align around outcomes." - "Sustainable change doesn’t come from mandates—it comes from treating transformation like an internal market." - "Focus on outcomes, not rituals. Do it because it’s useful, not because it’s prescribed." - "Real Transformation isn’t a rollout. It’s an invitation. An experiment. A conversation." - "When you force a solution that’s not ready for the mainstream, you kill its credibility." - "Ask yourself: Are you running a transformation… or just putting on a show?" **(00:00)** Introduction: The Reality of Transformations **(00:27)** The Pitfalls of Forced Transformations **(00:55)** The Illusion of Change: Vanity Indicators **(01:23)** The Missteps in Agile Transformations **(01:45)** The Frustration of Misguided Roles **(02:24)** The Problem with Mandated Change **(03:22)** A New Approach: Internal Market for Change **(04:38)** Empowering Teams: The Why Conversation **(06:13)** Principles for Sustainable Transformation **(07:07)** Organizing Around Value **(08:03)** Structuring Transformations as Experiments **(08:52)** Validating Desirability **(09:33)** Conclusion: Are You Running a Transformation or a Show? **Ready to stop running a show?** 👉 Begin with Yuval's free email course: [Scaling w/ Agility Crash Course](https://pages.yeretagility.com/scaling-w-agility-crashcourse)

Forever Flywheels?

Yuval Yeret — Mon, 28 Jul 2025 00:00:00 GMT

Flywheels are all the rage these days. I'm a fan as well. “No matter how dramatic the end result, the good-to-great transformations never happened in one fell swoop. Rather, the process resembled relentlessly pushing a giant, heavy flywheel…turn upon turn, building momentum until a point of breakthrough.” (Jim Collins, Good to Great) A key attribute of a flywheel is the self-reinforcing loop. Some examples of Flywheels in the agility/product space - - **Safety Nets -** Investing in test automation and collective ownership that, over time, creates more flexibility in the team, reducing bottlenecks, and creating even more safety and capacity to invest even more in test automation and collective ownership - **Working ON the Org/Business -** Investing in improvement in general. Spending time ON your business/organization is very hard when there's no "momentum" - when you need to keep turning the wheel to keep it moving. But as you invest in improvement, you start to build momentum, and things become somewhat easier. The same amount of work on the business results in more and more impact, and more and more capacity to focus on the business. - **Descaling** \- Investing in team empowerment/autonomy - can be very challenging when you have a tightly coupled organization. Just getting the teams talking about their dependencies seems to take all the energy and time you have. But as you start to invest in descaling, you make integration and coordination somewhat easier. Which frees capacity and builds momentum and conviction to do more and more of that. Consistency is crucial for all of these examples. It's not about "installing a framework" and then moving on. It's about the grit and the grind. You can't talk about Flywheels without talking about their nemesis - the Doom Loop. (aka Downward Spirals) Tech Debt, Quality Issues, and Hero Culture are a few examples that immediately come to mind. ## Look at your organization: Can you identify your flywheels? Your doom loops? Look at both your ways of working and your actual product/business.

Uncomfortable Truths About The Agile Industry's Focus on Vanity vs Outcomes

Yuval Yeret — Thu, 17 Jul 2025 00:00:00 GMT

[https://api.substack.com/feed/podcast/1195288.rss](https://api.substack.com/feed/podcast/1195288.rss) In this special crossover episode of *Mastering Agility* and *Scaling with Agility*, Yuval Yeret joins Jim Sammons and Rick Visotcky to confront the uncomfortable truths about the agile industry. Together, they explore why so much agile work has drifted into activity for activity’s sake and how coaches, trainers, and leaders can realign their work to drive meaningful outcomes. The conversation strikes a balance between candor and pragmatism, reflecting on the courage required to challenge the status quo while acknowledging the human realities of making a living. If you’re grappling with agile theater and wondering how to bring more integrity to your practice, this discussion is a timely call to action. ## Highlight Quotes / Concepts - The tension between *certification-driven training* and *real transformation* - The impact of commoditization on agile roles and courage - How financial independence or reputation can enable principled interventions - The idea of “forever employable” as a foundation for sustainable courage --- ## Chapters **(00:00)** Introduction and Speaker Introductions Meet Yuval, Jim, and Rick, and hear about their backgrounds in agile training and coaching. **(01:55)** Discussing Outcomes in Agile Training Exploring the irony of teaching outcome-focused techniques in a fundamentally output-driven training industry. **(05:07)** Challenges in Agile Training and Consulting Yuval shares why current success metrics—certifications, butts in seats—are broken, and what it could look like to hold trainers accountable for real impact. **(10:17)** The Reality of Agile Roles and Industry Issues Jim and Rick reflect on why the agile staffing and consulting ecosystem struggles to focus on value, not vanity metrics. **(13:41)** Balancing Principles and Practicality A candid conversation about the personal and systemic conflicts between paying bills and doing the right thing. **(23:10)** Courage and Safety in Agile Coaching Discussing Maslow’s hierarchy, courage, and why psychological safety is foundational to speaking truth to power. **(37:47)** Conclusion and Future Topics A look ahead to exploring what it *really* means to “put your own mask on first” in an agile career. --- ## Notable Quotes > “We are guaranteeing the wrong things. We’re focused on vanity metrics. What would it look like if we started to focus on outcomes?” > — Yuval Yeret > > “There’s no courage in safety. If you’re already safe, what do you need the courage for?” > — Rich Visotcky > > “The unemployment line is full of people with strong principles and values.” > — Jim Sammons > > “Forever employable is something that is a good outcome for agileists to strive for—because that’s the only way they can be real agileists.” > — Yuval Yeret --- ## Guest Links and Resources - Mastering Agility Podcast - [Jim Sammons on LinkedIn](https://www.linkedin.com/in/jim-sammons/) - [Rich Visotcky on LinkedIn](https://www.linkedin.com/in/visotcky/) - *[Forever Employable](https://jeffgothelf.com/foreveremployable/)* [by Jeff Gothelf](https://jeffgothelf.com/foreveremployable/) - *[Sense and Respond](https://www.senseandrespond.co/certified-training-partner)* [training partners](https://www.senseandrespond.co/certified-training-partner) --- ## Call to Action **Suggested Experiment:** Reflect on your own engagements: Are you measuring success by activity or by evidence of meaningful change? Try defining a “no-OKR”—an explicit non-goal—for your next engagement to clarify focus and reduce vanity work. --- ## Find the Scaling w/ Agility Podcast on your favorite Podcast Player: --- _Moving from agile theater to real business agility takes more than a framework — it takes a deliberate operating model shift. [Explore Business Agility advisory](/work-with-me) or [let's talk](/work-with-me)._

Clemens Adolphs on the Role of Agility in Getting AI Investments Right

Yuval Yeret — Tue, 15 Jul 2025 00:00:00 GMT

[https://api.substack.com/feed/podcast/1195288.rss](https://api.substack.com/feed/podcast/1195288.rss) In this episode of the *Scaling With Agility* podcast, host **Yuval Yeret** welcomes **Clemens Adolphs**, co-founder of **[AIce Labs](https://www.aicelabs.com/)**, a company specializing in helping organizations successfully implement AI initiatives. Their conversation dives into the intersection of AI and agility, exploring how to avoid the all-too-common proof-of-concept trap and instead focus on delivering genuine outcomes. From internal market validation to adapting agile methods to the unique context of AI projects, this discussion is essential listening for leaders who want to scale AI initiatives without falling into process theater. --- ## Highlight Quotes / Concepts - Why most AI proofs of concept never scale—and what to do instead - Internal market validation as a critical success factor - Adapting agile practices to the unique uncertainty of AI - Recognizing and preventing common anti-patterns when combining AI and agility --- ## Chapters **(01:28)** Clemens Adolphs’ Background and Journey into AI Implementation **(03:46)** Challenges Organizations Face When Bringing AI into Production **(09:02)** The Role of Prototyping and Experimentation in AI Projects **(11:09)** Why Internal Market Validation Beats Metrics Theater **(16:29)** Collaboration Models and Execution Patterns for AI Work **(23:10)** Agile Practices and Anti-Patterns: What Works and What Doesn’t **(38:13)** Closing Remarks and How to Connect with Clemens --- ## Notable Quotes > “The proof of concept is where AI projects often go to die. You need to design for internal market validation early on.” — *Clemens Adolphs* > > “Agile is not a one-size-fits-all recipe—especially when you’re dealing with the inherent uncertainty of AI.” — *Yuval Yeret* > > “Metrics are useful, but if they’re not tied to actual adoption or impact, you’re just performing success, not achieving it.” — *Clemens Adolphs* --- ## Guest’s Links and Resources - **[AIce Labs](https://www.aicelabs.com/)** - **[Follow/Connect to Clemens Adolphs on LinkedIn](https://www.linkedin.com/in/clemens-adolphs-7473a392/)** --- ## Yuval **Yuval Yeret** helps leaders maximize outcomes through strategic, nuanced agility. These days, he’s focused on helping business leaders of mid-market/scaleup companies improve time to impact on strategic investments such as AI transformation. As a Product, Scaling, and Agility-focused management consultant, he’s worked with companies across tech, R&D, biotech - supporting both product/tech organizations as well as the broader business in delivering better outcomes using agility. **[Follow Yuval on LinkedIn](https://www.linkedin.com/in/yuvalyeret/)** [Developing your AI capabilities using Agility](/blog) ## Find the Scaling w/ Agility Podcast on your favorite Podcast Player:

How to Drive Towards Business Agility Without Falling Into Transformation Theater - Fireside Chat with Jesper Boeg

Yuval Yeret — Mon, 14 Jul 2025 00:00:00 GMT

[https://api.substack.com/feed/podcast/1195288.rss](https://api.substack.com/feed/podcast/1195288.rss) 🎯 Episode Overview Yuval Yeret sits down with Jesper Boeg, an experienced transformation leader. Jesper has spent nearly two decades guiding organizations from team-level agile adoption to enterprise-wide agility. Together, they explore what *real* business agility looks like—beyond frameworks, dogma, and agile theater. The discussion dives into the evolving role of CXOs in driving adaptability, the pitfalls of applying agile practices indiscriminately, and the nuance required to align strategy, funding, and organizational design. This conversation is especially timely as leaders grapple with AI transformations, product-led growth, and the pressure to scale without losing focus or authenticity. 💡 Highlight Quotes / Concepts **“Don’t go in trying to find nails in the organization with your hammer. Go in light, try to sense, try to nudge.”** **“If your funding is not matching how you’re set up, you’ll never move from your old strategy to your new one.”** **“Consistency doesn’t mean uniform mechanics—it means shared principles and clear interfaces.”** **“Business agility isn’t about sprints for HR. It’s about creating shorter lead times, better discovery, and the strategic adaptability to stay ahead.”** ⏱️ Chapters **(00:00)** Welcome and Introduction to Scaling with Agility **(00:30)** Meet Jesper: From team-level agile to enterprise transformation **(02:00)** The evolution of business agility and why it’s now a CXO problem **(03:00)** Defining business agility beyond rituals and frameworks **(04:00)** Jesper’s three elements of business agility: lead time, discovery, and strategic adaptability **(09:00)** Challenges of applying agile principles in the wrong places **(14:00)** Yuval’s story: Helping a biotech C-suite use agility to work *on* the company, not *in* it **(18:00)** Strategy before structure: Conways Law in action **(20:00)** Funding and capacity as critical levers for transformation **(22:00)** Lightweight interventions: Using simple boards to start the conversation **(25:00)** The importance of vertical slices vs. big bang transformation **(30:00)** AI transformation as a strategic bet: Applying product thinking internally **(33:00)** The danger of copy-paste scaling after early success **(36:00)** Principles over frameworks: Avoiding dogma and focusing on intent **(40:00)** Consistency, interfaces, and the challenge of defining the “API” for teams **(43:00)** Metrics, observability, and the risk of vanity measures **(48:00)** Why understanding the *why* behind principles matters more than tracking every number **(51:00)** Real product organizations vs. labeling technical solutions as “products” **(53:00)** Final advice: Start by defining what’s core, what’s context, and what truly matters **(55:00)** Closing thoughts and where to find Jesper online ✨ Notable Quotes _“If you cannot stay ahead of the curve, then your entire strategy is at risk.”_ _“Business agility is an agile operating system for your business, not just your product value stream.”_ _“I’m not in business to supply usable solutions for the transformation office. I’d rather have people passionate about their products and their ways of working.”_ _“The law of the raspberry jam applies—when you spread too thin, you lose your effectiveness.”_ [Enterprise Movement](https://www.enterprisemovement.com/) **Jesper on LinkedIn:** [Jesper Boeg](https://www.linkedin.com/in/jesperboeg) **Recommended Reading:** *Crossing the Chasm* by Geoffrey Moore (on early adopters and scaling) [How to apply crossing the chasm to transformation (Yuval's talk)](https://prezi.com/eotlextweb80/kanban-a-sane-way-towards-agility-in-the-enterprise/) *Lean Startup* by Eric Ries (on build-measure-learn loops) **Try this:** Identify one strategic initiative in your organization—perhaps AI transformation or a shift to subscriptions. Instead of launching a company-wide program, explore applying a *vertical slice* approach: build a cross-functional team, empower them to iterate, and measure outcomes in a contained context. Or, take Yuval’s free *Scaling with Agility Crash Course* to explore how to scale without falling into the process theater trap 👉 [Scaling w/ Agility Crash Course](https://pages.yeretagility.com/scaling-w-agility-crashcourse) ## Find the Scaling w/ Agility Podcast on your favorite Podcast Player: --- _Moving from agile theater to real business agility takes more than a framework — it takes a deliberate operating model shift. [Explore Business Agility advisory](/work-with-me) or [let's talk](/work-with-me)._

A Simple Way to Get a Grip on Your Goals

Yuval Yeret — Sat, 12 Jul 2025 00:00:00 GMT

You’ve probably heard the saying, _What gets measured gets managed._ But just setting big goals—like OKRs—isn’t enough on its own. If you’re not careful, those goals can pile up, get stuck, or drift out of sight. Before long, you’re wading through what I call the _OKR swamp_—lots of plans, not much progress. A straightforward way to avoid this is to put all your goals on one visible board—a single place where you and your team can see what you’re aiming for and how it’s going. ![](/assets/images/blog/OKRs-Kanban_2025-01-24_19-02-10-1024x557.png) --- Here are a few ways I’ve seen this work well: Instead of keeping each department’s goals hidden in their own documents, bring them together on the same board. It helps everyone understand not just their own priorities but where they overlap—or clash—with others. Map out the journey each goal takes. Start with ideas you’re considering. Then move to goals you’re committed to, what you’re actively working on, and finally, where you step back to reflect on what worked. This rhythm keeps you from slipping into a “set it and forget it” habit. Be honest about whether goals are really moving forward. For example, mark each goal as Red, Yellow, or Green. Start everything in Red, and only shift it forward when there’s real evidence of progress. This helps you focus on what’s stalled, rather than what's flowing well. Limit how many goals you’re working on at once. When everything’s a priority, nothing is. Show who’s involved in each goal. If you notice the same people spread across too many commitments, that’s worth a conversation. And remember, if your board starts looking too crowded or confusing, that’s a signal. It means you might have too much in play, or not enough clarity about what matters most. Make it a habit to check this board when you review progress or think about new ideas. It’s a simple way to spark better conversations and keep your goals from sinking into the swamp. ## How are you managing your Goals? I’d love to hear what’s worked for you.

Spraying GenAI Everywhere? Try This First

Yuval Yeret — Fri, 11 Jul 2025 00:00:00 GMT

Everyone’s asking: _How can we use GenAI to grow faster? Sell more? Keep customers longer?_ Here’s the thing—rolling out GenAI across your business isn’t just about flipping a switch. It’s messy. There’s uncertainty. You’ll try things that don’t work. You’ll learn. You’ll adjust. In other words, it’s precisely the kind of challenge that benefits from an agile, experimental mindset—not just for building products, but for building how your company _operates_. I see too many companies spraying GenAI around like fertilizer, hoping something sprouts. A better approach? Slow down. First, take a hard look at the bottlenecks in your business—the critical processes that waste time, drain energy, or block growth. Those are the areas where improvements through AI can move the needle. _"An hour_ _**lost**_ _at a_ _**bottleneck**_ _is an hour out of the_ _**entire system**\_\_. An hour_ _**saved**_ _at a non-bottleneck is_ _**worthless**\_\_." Eliyahu Goldratt, the creator of the Theory of Constraints (TOC)_ But even when focusing on the bottleneck, don't rush to plug in a shiny AI tool. First, implement some basic process improvements. Tighten things up. Clarify how the work _should_ flow. Once you’ve got something stable and sensible, **then** you can ask, “How might GenAI help us do this faster or better?” For example, maybe you notice your sales team spends hours each week copying data between systems—CRM, spreadsheets, proposals. It’s tempting to jump straight to “Can GenAI automate this?” But first, ask: _Do we really_ _**need**_ _all these handoffs?_ Maybe you can rework your process so one system is the single source of truth. Maybe you can delegate approvals. Try that first. Let people live with it for a few weeks. See what changes. Once you’ve simplified, **then** bring in GenAI—maybe to auto-draft proposals or summarize meeting notes. Or take customer support. Perhaps your team wants GenAI to respond to all incoming emails. But if your help center articles are outdated and your processes are inconsistent, the AI will just give faster wrong answers. GenAI can be powerful. But it’s smarter to aim it at the right places, get ready for it, and steer it using old-fashioned human effort,

From FOMO to JOMO

Yuval Yeret — Thu, 10 Jul 2025 00:00:00 GMT

You start hearing about the next thing—EOS, Agile, Scaling Up, AI. At some point, there's enough FOMO (Fear Of Missing Out) that you feel like you SHOULD do something about it. I've had numerous business leaders reach out and ask me to help them "**do the thing**" (the latest example being AI Transformation). When that's the ask, adopting a new thing (process, tool, approach) **fizzles** more often than not. Because you don’t **really** care about the thing for its own sake, you care about **expensive problems.** Let me suggest a prediction: If you're entering AI Transformation mainly out of FOMO, it will soon turn into JOMO (The **Joy** of Missing Out) That's precisely what I've observed happening with Agile, Scrum, OKRs, and EOS in the past, and I'm already seeing it occur with AI. **Want to sanity-check a big idea before you invest?** Instead of blindly following your FOMO, consider having a 'why' conversation. (This is the conversation I have with leaders who reach out to make sure we head towards real impact instead of JOMO, but you can have it with yourself, or even your favorite GenAI chatbot... ) **Write down:** - The _problem_ you’re solving (who has it, why it matters) or the _opportunity_ you want to leverage - The _business impact_ you expect if you solved/leveraged it. - Why is this _so important_ to you? Why deal with it _now_? _Why not wait a couple of months before we tackle it?_ - The _behavior change_ you expect (who will do what differently, by how much) - _What are the alternatives? What have you tried? What else might do the job instead of doing this thing?_ - The central _hypothesis_ you’re betting on (we believe \[_business impact\]_ will be achieved if \[_who\]_ attains \[_benefit\]_ through the \[_thing\]_) If you're still in FOMO mode, think deeper about: - The _smallest experiment_ you can run to test it - The _signals_ you’ll watch to know if it worked If you can’t see the connection between the thing and your most expensive problems or most lucrative opportunities, it probably isn’t worth your time. If you **can** see the connection, you have just framed the initiative in a way that makes it clear **why** you're focusing on it, what the outcomes are to align towards, and empowers everyone to make the right decisions to **steer it** along the way based on what you learn. All of which will dramatically improve the odds of getting real value out of this initiative, rather than it becoming another tombstone in the initiative graveyard. May the odds be ever in your favor ([improve your odds by applying product techniques to develop your company...](/blog))

The Irony of Managing a Product Transformation like a Project

Yuval Yeret — Wed, 09 Jul 2025 00:00:00 GMT

The next time a big consultancy pitches a transformation - let's say a project to product transformation – ask them how they recommend managing it. And see if what they describe looks more like a Project or a Product. For example, Will they measure [vanity metrics or product metrics](https://preview.convertkit-mail2.com/click/dpheh0hzhm/aHR0cHM6Ly95dXZhbHllcmV0LmNvbS9ibG9nL2FhcnJyLXBpcmF0ZS1tZXRyaWNzLWZvci1jaGFuZ2UtYWRvcHRpb24v)? It just goes to show how tempting these vanity metrics are. How hard it is to talk about the real WHY (especially when the WHY is because a big consultancy firm sold us on it…) How frightening it is to look at the actual outcomes of our initiatives. Here's the thing... As change agents driving a product operating model, we are asking people to behave differently. We should show them how that looks: Starting with a hypothesis: _We believe that we will achieve stronger, more sustainable growth if product teams can deliver measurable customer outcomes with a product operating model that gives them end-to-end ownership and clear success metrics._ (Don't copy-paste - create your own!) Provide leading indicators, for example - - % of product teams who can clearly state their product mission and intended outcomes (ideally without looking it up) - % of new product initiatives that go through hypothesis prioritization to determine whether to test, ship and measure, or drop - % of new product initiatives that require testing undergo a discovery/truth curve process. - % of product teams report they are empowered at the right level to make decisions - % of product teams report fewer dependency overhead For Key Results / Success Criteria, move from % to a discrete result, e.g., 80% of product teams can ... And don't forget Kill Criteria, such as after **6 months**, fewer than **30%** of teams can articulate their mission and outcome metrics What do you think will happen once you start treating your product operating model transformation as a product initiative (instead of a project)? ## Interested to learn more? Explore the [Product-Oriented Portfolio Agility Trail Map](https://preview.convertkit-mail2.com/click/dpheh0hzhm/aHR0cHM6Ly95dXZhbHllcmV0LmNvbS90aGUtcG9ydGZvbGlvLWFnaWxpdHktdHJhaWwtbWFwLw==) for in-depth insights into applying product thinking for product transformation.

Moving from Project to Product Ownership for your Cross-Org Initiatives

Yuval Yeret — Tue, 08 Jul 2025 00:00:00 GMT

How do you manage your cross-organization initiatives? Those are some of the most significant, complex endeavors companies take on. They are often strategic bets for the organization, yet they are often very frustrating to manage. So frustrating that these are often the reasons leaders start thinking about bringing on project managers... who: - Apply very tight control for the whole project - tracking to committed scope and agreed upon project plan - Spend a frustrating amount of time planning and coordinating activities - Try to minimize change (processes such as change control and change request start appearing) While there's much more control, and sometimes even signs of traction towards the project plans, outcomes are still elusive. We've learned a lot about project management in the last decades. We've learned that when working on a complex problem, it's essential to prepare for the unexpected. The plan becomes useless the moment you enter the ring with your opponent. The way to improve your odds is to manage differently. Let's take inspiration from how we've been tackling this challenge in product development. For starters, we've moved from managing projects to managing products - focusing on achieving outcomes and business impact while being flexible with activities and deliverables. The cool trick is that this thinking applies even when beyond classic product development. Your move from perpetual to subscription licensing? you can treat it as a product designed to change behaviors and deliver an impact Your adoption of a new talent acquisition approach? yes Moving from a focus on bespoke projects for clients to a stronger product foundation? yes And once you start tackling your initiatives this way, you can leverage **Product-oriented Initiative Ownership**, which means the people who take ownership of an initiative: - Act as a visionary for their strategic initiative. - Own the Outcomes - Connect to customers, - Collaborate with a multitude of teams on finding creative and effective ways to test and deliver outcomes. - Make critical decisions as well as decentralize when possible while providing clarity and context. - Focus on the risks/uncertainties and create discovery and delivery plans that provide plenty of opportunity to inspect, adapt, or stop. - Leverage influence to drive collaboration towards outcomes across multiple products and departments. ## You might say they act like Professional Scrum Product Owners…

Developing Your AI Context as a Product

Yuval Yeret — Wed, 02 Jul 2025 00:00:00 GMT

_Context is King_ You've probably encountered this term in the context of AI. You won't get far with AI, even with amazing prompting techniques, if AI doesn't have the right context. Many people focus on the Data aspect of context - what's in our CRM, in our collaboration tools, in our ERP, in any of our vertical systems. Another interesting aspect is the intent - what are we trying to achieve? What is our strategy? What problems are we focused on? Who are the players? Some of that information could be ascertained by inhaling data from systems. But as you've probably seen if you're playing around with AI - it still has context limits, so there's value in shaping and emphasizing. For example - if I'm telling AI who are my ideal customers, what are the problems I'm focused on solving, what are the problems and opportunities I see in MY business, I'm getting much more value, even without advanced prompting. Think of it this way - Context is like a platform product. By creating the right context, you're reducing the cognitive load and expertise required for prompting, and getting better answers. If Context is King, and is a product, it brings about an interesting question - How should we "develop" this product? Do you already have someone responsible for Product Strategy for your AI Context? Do you have a Product Goal for it? A team that is focused on evolving it? Building an increment of the context, Shipping it (so people can use it), Sensing (whether its useful, using outcome-oriented leading indicators?), Responding? Do you have a Context Backlog containing opportunities to improve the Context? (e.g. Connecting it to more data, shaping it using JTBDs, personas, OKRs, problem statements, training it) What might it look like to apply product thinking and techniques in your AI transformation?

Transformation or Bling? What My Apple Watch Taught Me About Agile, OKRs, and Real Change

Yuval Yeret — Wed, 18 Jun 2025 00:00:00 GMT

When Vered and I got married, my father-in-law gave me a very nice watch as a wedding gift. I didn't wear a watch that often at the time. I wore the watch, but it didn't transform me. It provided the service of telling the time, but even back in 2004, we had phones that had clocks. And I was and am pretty punctual so didn't need that transformation. (And when you're in Engineering/IT leadership, nobody cares about the watch you wear... at least in Israel... ) Don't tell Eli, but that watch spent many years in a safe drawer. And my left wrist got a nice tan, comparable to the right wrist. Fast forward to 2019 or so, I decided to get an Apple Watch for myself. The Apple Watch DID transform me. It's "Close Your Rings" feature had the outcome of me paying much more attention to how much I move (or not), exercise (or not), and stand (or not). I chose to heed the nudges to "Close My Rings" and started to stand, move and exercise more. I don't always close my rings. I have better days/weeks and not so good ones. I could make it an Apple Watch Close Your Rings Theater. I COULD just set my move ring to 100 calories a day. Stand for one hour. And exercise 15 minutes. I could ignore the rings altogether. But I strive to level up over time, rather than regress. Here's the thing... The work management tools and practice you're using are very much like my Apple Watch. Kanban/Agile/OKR/Scrum/Post Its/Liberating Structures/SAFe/Product Model CAN transform you. ## It can also be fancy bling theater.

Can you really run product discovery experiments more effectively with AI?

Yuval Yeret — Tue, 17 Jun 2025 00:00:00 GMT

_"GenAI can enable cheaper, faster experimentation / discovery (it compresses the truth curve by reducing the cost of pretotyping style product experimentation techniques)"_ (Yours truly, in yesterday's insight on [how AI can really help you build better products](/blog/how-can-ai-really-help-you-build-better-products)) This statement seems to have hit a nerve with reader Elad, who is product leader at a cybersecurity scaleup: _"Not everyone can do this... New companies, sure. Larger, established companies are knee-deep in mountains of code, dependencies, and tech debt. Whenever you need to build an MVP that depends on your existing product, good luck..."_ Elad is right. His comment echoes my initial assumption, which is that the jury is still out on how helpful "vibe coding" and GenAI code can be for large-scale brownfield/legacy software products in general. The interesting opportunity I'm highlighting here is that GenAI, in general, and vibe coding, specifically, can make it easier to experiment in the pre-MVP stage, also referred to as [Pretotyping](https://www.pretotyping.org/). Some of these experiments don't even require coding. But a product team could run a landing page, a fake feature, an explainer video, and other prototyping techniques much faster using GenAI as an accelerator. When you have built enough confidence in the truth curve that it makes sense to build an MVP, vibe coding should be considered as an approach to create a real, throwaway experiment intended to validate or invalidate. Indeed, there will be some environments where the only way to conduct meaningful experiments will be to build something that integrates with your existing system or product; in such cases, vibe coding might not be beneficial. In these cases, it may be beneficial to allocate more time to building higher conviction through pre-MVP discovery and experimentation techniques, before proceeding to expensive development in your real product code. Yes, new product development in a greenfield **is** easier in many ways. The advantage that product teams with existing products and customers have is precisely that - **they have these customers**. It **should** be easier for them to have **conversations** with these customers about problems, opportunities, needs, and jobs they're trying to get done. **You win some, you lose some...** Have you used GenAI as an early pre-MVP experimentation technique? I'd love to hear about your experience...

How can AI REALLY help you build better products?

Yuval Yeret — Mon, 16 Jun 2025 00:00:00 GMT

While the jury is out on the extent of impact GenAI and vibe coding will have on building mission-critical enterprise products... Here are some thoughts on how AI can help turn the product flywheel: - Use GenAI to enable fuller-stack engineers and reduce tech debt - This will enable you to organize smaller product/outcome oriented teams - These teams can achieve more with fewer dependencies and streamlined processes (even without looking at opportunities to streamline product dev processes themselves by using AI) - GenAI can enable cheaper, faster experimentation / discovery (it compresses the truth curve by reducing the cost of pretotyping style product experimentation techniques) - Cheaper experimentation allows for more "shots" for the same innovation capacity. - Which leads to faster product market fit, more likely product/feature fit - As well as reduced toil related to "failure demand" (customer who misunderstand the product, product failures, etc.) - Freeing even more capacity to discover/explore/grow/reduce technical debt / improve the architecture As this flywheel turns faster and faster, the product organization delivers better and better products and outcomes in an increasingly sustainable and resilient manner, with product organization operating systems that become simpler and more streamlined over time, rather than more complex. What are some additional ways you're leveraging GenAI to help turn the Product flywheel?

Michael Gerharz on Breaking Out of Agile Theater and Communicating Real Value

Yuval Yeret — Wed, 04 Jun 2025 00:00:00 GMT

[https://api.substack.com/feed/podcast/1195288.rss](https://api.substack.com/feed/podcast/1195288.rss) Ever get the feeling you’re the “agile person” in the room—brought in to run ceremonies, fix Jira boards, or play Scrum cop, but never actually invited to shape real strategy? If that hits close to home, you’ll want to listen in on my latest conversation with Michael Gerharz. Michael’s a computer scientist by training, but these days he’s known for helping leaders and teams find the right words so their ideas actually land—rather than getting tossed in the trash. We dug into why so many agilists get stuck in what I call Process Theater: going through the motions, checking the boxes, but never really influencing the game. Michael sees the same pattern—agile as theater, not progress—and he’s got some hard-won insights about why it’s so damn hard to speak uncomfortable truths in organizations that just want to “do agile” rather than be agile. We riffed on three big themes: – Why it’s so tough to communicate the real value of agile work (and why so many leaders default to checklists and ceremonies instead of outcomes) – The human tendency to avoid nuance, especially when LinkedIn and the broader business culture reward black-and-white takes – How to actually show up as a strategic partner, not just a tactical commodity Michael introduced his PATH framework (Plain, Actionable, Transformative, Heartfelt) as a practical way for agile leaders to bridge the gap—ditch the jargon, speak the language of the business, and connect with what actually matters to stakeholders. If you’ve ever felt like your agile expertise is being wasted on the wrong conversations, this episode will give you new ways to break the cycle. https://youtu.be/7V\_Zy1JIAAU Want to go deeper? Check out Michael’s book, [The PATH to Strategic Impact](https://michaelgerharz.com/the-path/), or grab his free [PATH in a Nutshell guide](https://michaelgerharz.com/path-in-a-nutshell/) for a quick hit of the core ideas. Want more? Subscribe to the Scaling w/ Agility Podcast on your favorite Podcast player: --- _If this conversation reflects what you are seeing in your organization, continue with [Fixing Your Agility](/work-with-me/fixing-your-agility/) or [Work With Me](/work-with-me/)._

How To Evade Coordination Tax By Organizing Around Outcomes

Yuval Yeret — Wed, 28 May 2025 00:00:00 GMT

Picture this: you've a breakthrough strategic initiative tied to one of your company-level goals that impacts 10 teams across two product groups, as well as your GTM organization. These are all busy, overloaded teams. Those same 10 teams are also juggling five other initiatives. And the business-as-usual whirlwind. You pull this work into the backlogs/roadmaps for all of these teams. fractional slices of people across the teams will work on this. Which means it will take a while. Leaders involved with all these teams will need to be involved to coordinate. How fortunate we are to have mechanisms in place to coordinate all of this. (Think PI/Quarterly planning, JIRA Align, Product Owners with their different backlogs, Solution Trains, and a complex network of cascaded OKRs) Sound familiar? This is what I call the **coordination tax**—that hidden cost of trying to innovate across organizational boundaries that weren't designed for the outcomes you're pursuing. ## The Gillette Experiment When we worked on the Gillette Exfoliating Razor, we tried something different. Instead of accepting the coordination nightmare, we asked a simple question: "If we had free reign, what's the minimum number of people we'd need if they could really focus?" The answer was about 30 people from across the R&D, Commercial, Marketing, Finance, Prep for Manufacturing teams. Instead of feeding the work into the teams all these people belonged to, we created what you might call a **virtual value center**—5 virtual teams that existed solely to figure out a winning proposition and get it to market. Same amount of brainpower, spread over fewer people, concentrated to a shorter time, with less managerial overhead both because people were already working with the people they needed to coordinate with, as well as the shorter timespan. It required some tough prioritization tradeoffs. It highlighted some islands of knowledge. But it was worth it. The Exfoliating Razor became one of Gillette's most successful products many years, developed and brought to market faster than anything they'd done before. ## It's not about the process Here's the thing. The breakthrough wasn't about agile ceremonies or new tools. It was about **the coordination** **and collaboration architecture**—designing your organization so that people can concentrate on what matters most. Most organizations strive to optimize resource utilization, keeping everyone engaged across multiple initiatives. But innovation requires optimization for flow, getting the most valuable outcomes through the system as quickly as possible. Now, let's be honest about the constraints. Carving out focused teams isn't trivial. You'll hit knowledge islands where someone needs to split their time. You'll face resistance from leaders who don't want to "lose" their people to a cross-functional effort. And you'll discover dependencies you didn't know existed. At Gillette, we had some advantages—executive commitment made the tradeoffs possible. Even then, certain specialists (like material designers) couldn't focus 100% and had to play "floater" roles across initiatives. And remember - we did this just for the #1 strategic priority, not across the board. ## Try this at work That's an intervention pattern I've seen work well - Identify a strategic priority that requires intense cross-functional collaboration and faces significant feasibility/desirability risks. And experiment with this approach for that initiative - where there's clear concern that the current ways won't deliver the desired outcomes or would be too painful to manage. Here are some even easier interventions to consider, that can help you identify and build the conviction to try this: - Map your current people to your strategic initiatives and count how many teams and people are working on multiple efforts simultaneously. Set that as a KPI—your "Focus Factor"—and work to improve it over time. - Use a "Portfolio"-level Kanban to bring more transparency to how many initiatives you're working on at the same time. And to start conversations about managing the amount of initiatives in progress, especially those that cut across the organization. ## Conscious Focus over Perfect Focus Remember - The goal isn't perfect focus (that's rarely possible), but conscious focus. When you're explicit about the tradeoffs, you can make better decisions about where to accept coordination costs and where to eliminate them. This isn't about implementing a new methodology—it's about **organizing around outcomes** rather than org charts. Whether you call it value streams, empowered teams, or virtual pods doesn't matter. What matters is creating conditions where people can actually deliver on what you've asked them to deliver. The Gillette experience taught us that sometimes the biggest constraint to innovation isn't technology or market conditions—it's how we organize ourselves to do the work. When you align structure with strategy, remarkable things become possible. [https://api.substack.com/feed/podcast/1195288.rss](https://api.substack.com/feed/podcast/1195288.rss) ## Find the Scaling w/ Agility Podcast on your favorite Podcast Player: --- _Scaling Agile with SAFe requires more than certification — it takes context-sensitive implementation. [Explore SAFe advisory](/work-with-me/scale-agility-leveraging-the-scaled-agile-framework) or [let's talk](/work-with-me)._

Fixing Your OKRs Using AI

Yuval Yeret — Tue, 27 May 2025 00:00:00 GMT

Please don't write your OKRs using AI. OKRs should reflect YOUR strategy. Your choices. Your strong opinion. Your tradeoffs. What you CAN do is use AI to fix your OKRs. Here are some ways you could go about doing that: 1. Collaborate with AI to create a prompt that reflects your perspective on what makes great OKRs 2. Point AI at an OKR expert you're following and tell it to create a prompt based on that expert's advice. (Your OKR Hot Seat with that expert) 3. Point AI at a set of OKR experts and ask it to create a prompt to act as an OKR advisory board, weaving in the expertise/advice from the panel of experts. 4. Read an OKR-related book or take an OKR-related workshop, and take notes in the form of an AI prompt. Whatever way you create this prompt, I like to save it as context, for example, as instructions or a file attached to a Perplexity space. One of the advantages of this approach is that it works even when using an enterprise LLM, which is often more secure but weaker than publicly available ones. Once you create the prompt wherever you want, you can take it inside the firewall and use it on your enterprise OKRs without the risk of sharing your strategy and priorities with a public large language model (LLM). ## P.S. I'm sharing my 'Fix Your OKRs' AI prompts. [Get them here](https://pages.yeretagility.com/fixyourokrs-ai-swipe)

How To Break Process Theater Using Outcome Orientation

Yuval Yeret — Mon, 26 May 2025 00:00:00 GMT

Picture this: You’ve invested in a framework, maybe rolled out Agile, SAFe or OKRs , and your teams are “following the process”. But despite all the activity, the promised business impact just isn’t showing up. Sound familiar? If so, you might be caught in Process Theater - a situation where everyone’s performing the rituals, but the outcomes you care about never materialize. [(Prefer Audio? This article is available as an episode of the Scaling w/ Agility Podcast)](/yuvals-scaling-w-agility-podcast) Let’s explore why this happens, how to spot it, and—most importantly—how to use outcome mapping to move from process compliance to real, sustainable traction. What Does Process Theater Look Like? First, let’s get clear on the symptoms. Process Theater isn’t about bad intentions. Most teams and leaders genuinely want to improve. But what you’ll see is a focus on mechanics over meaning. Teams spend 80% of their energy on following the process to say “we’re doing it,” not because they see the value. Take OKRs as an example. If your organization is measuring success by whether OKRs exist, not whether they’re helpful, you’re in OKR Theater. You’re tracking the presence of objectives and key results, but nobody’s using them to drive decisions or create alignment. It’s activity masquerading as progress. ## **The Underpant Gnomes Problem: Missing the Middle Layer** Why does Process Theater take root? It usually starts with a reasonable goal - maybe leaders want more alignment or sharper focus. But instead of connecting the dots between the process and the intended impact, everyone jumps straight to implementation. It’s the classic “[**underpant gnomes**]()” problem: Step 1, collect underpants (run standups, write OKRs); Step 3, profit (achieve alignment). Nobody can explain Step 2 - how the process leads to your desired outcome. ![](/assets/images/blog/9v5di6.jpg) This missing middle layer is the connective tissue: the actual behaviors and outcomes that bridge process and impact. Without it, you end up with a lot of motion, but not much movement. ## **Alignment with Autonomy: The Real Goal** Let’s take OKRs again. The intent behind OKRs isn’t just to document objectives and key results in a tool. It’s to create alignment with autonomy. You want people moving in the same strategic direction but with the freedom to figure out how to get there. That’s the heart of agility: aligned AND empowered teams. But to get there, you need to define the behaviors you want to see. Instead of teams writing OKRs because they were told to, you want teams that understand the strategic context and can make decisions themselves. For leaders, it means providing clear intent and stepping out of the way, trusting teams to own the “how”. ## **Building Trust and Empowerment** So, how do you build that trust? Leaders need to know what teams are working on - at the right level of detail - and see evidence of traction. When teams focus on a few key things and deliver tangible progress, it builds trust. That trust, in turn, leads to more empowerment and more decentralized decision-making. Over time, you get a positive flywheel: more trust leads to more autonomy, which leads to better outcomes, which builds even more trust. But it doesn’t happen automatically. In most organizations, leaders are used to being involved in every decision. Sometimes, this is inertia, and sometimes, it’s a lack of trust. ![](/assets/images/blog/Outcome-Mapping_2025-05-25_18-48-05.png) ## **From Outcome Map to OKRs** Once you map out the outcome - the behavior you want to change, you can define it as a key result in a change-focused objective. Here's one way this could look: ``` Objective: The majority of our innovative knowledge work takes place in aligned and empowered teams that have the autonomy and ability to innovate, experiment, sense, and respond by the end of the year. ``` ``` Key Result: Leaders let their teams figure out what to build 80% of the time. ``` You could stop here. You identified the behavior you want to see. By setting this as your OKR, you’re providing direction and flexibility. You’re not dictating the activities or deliverables that would lead to leaders letting their teams figure out what to build more of the time. The team that would work on achieving this objective will have to hypothesize, ship, sense, and respond to techniques/interventions to try and move the needle towards this goal. Having said that, sometimes a bit more direction can be useful. While you should avoid telling teams exactly what to do, you could provide the direction that trust leads to empowerment/autonomy. ``` Leading Indicator Key Result: Leaders consider 80% of their teams to be accountable, predictable, and trustworthy. ``` ## **Closing the Curtain on Theater: Practical Steps** If you’re a leader and you sense process theater in your organization, here’s what I suggest: - Map out the specific behaviors that feel like theater. What are people doing just to check a box? - Walk back from those behaviors: What’s driving them? What’s the impact? Can you identify a downward spiral? - Reconnect with the original intent. What outcomes and impact are you after? - Use [**outcome mapping**](https://jeffgothelf.com/blog/why-you-should-map-outcomes-to-impact-metrics/) to clarify the chain from process to impact. - Look for interventions that stop the downward spiral and then start turning the flywheel towards the outcomes and impact you seek. - Set objectives and key results around these behaviors and outcomes, not vanity metrics, even if these are harder to measure. Prefer measuring qualitative outcomes and quantitative vanity. Prefer Video? Here's a deeper dive into this conversation: https://youtu.be/W8tvONB5yzM This article was inspired by the Sense & Respond Learning [**_Who Does What by How Much OKR workshop_**](https://www.senseandrespond.co/okr-master-class). ![](/assets/images/blog/WDWBHM-Sample-Cover-In-SQUARE-Copy.png) I recently joined [**Sense & Respond Learning**](https://www.linkedin.com/company/sense-and-respond-learning) as a Certified Training Partner and will teach the OKR Masterclass to help organizations leverage OKRs to move their product development and transformation efforts from outputs to outcomes. If you’re sick of process theater and the idea of evolving to focus on outcomes sounds interesting, [**let’s discuss how I can help**]({{DISCOVERY_URL}}).

Tackling Strategy Theater - Fractals To The Rescue (Yet Again)

Yuval Yeret — Sat, 17 May 2025 00:00:00 GMT

Are your strategic themes gathering dust like unused New Year's resolutions? If you're investing significant energy evaluating initiatives but your enterprise themes seem vague, unconnected, merely decorative, or too restrictive, you might suffer from "Strategy Theater." The frameworks these organizations use prescribe a strategy artifact. But the leadership team responsible for it hasn't boarded the business agility gravy train yet. Or they don't know how to. So they define an OKR or Strategic Theme the way they always have. Like our Epics, Features, Stories or whatever artifact you use in your product delivery organization, we'd like our strategy to clarify why now, where we want to play, and how we will win, in a way that enables aligned autonomy. Portfolio leaders at a firm I'm working with were doing great work bringing outcome-oriented and evidence-informed steering to the initiative level. We recognized that the strategic themes could benefit from the same improvement. It was beautiful to see Portfolio Managers starting to challenge themselves and their peers to bring more outcome orientation and optionality to their enterprise's strategy artifacts. Think about how the same patterns repeat at different organizational scales - like fractals in nature. Your delivery teams run experiments with stories, your product teams with features, and your portfolios with epics. Why stop the pattern there? - A Strategy Owner can be to a strategic theme what an Epic Owner is to an epic and what a Product Owner is to a Product - A Strategy Hypothesis could be to Strategies what an Epic Hypothesis is to epic-level initiatives. - a Strategies Kanban can bring discipline and realistic flow consideration to strategic thinking, like the Portfolio Kanban is bringing to the initiatives level. It can be leveraged to manage the lifecycle of potential strategies - from sensing a strategic threat/opportunity to responding to it. This isn't about adding complexity - it's about extending what already works with minimal addition. ## PS: How are you currently considering and developing your strategic themes? I'd love to hear if you've tried similar approaches to bringing outcome-oriented empiricism to strategy.

What To Do When Adoption of an Internal Tool/Process Stalls

Yuval Yeret — Wed, 23 Apr 2025 00:00:00 GMT

You've paid for that product license. JIRA Align. Copilot. ChatGPT. Maestro. Pendo. Gong. ServiceNow. Snowflake. Cascade. Monday. Clickup. (Engineering|Product|Rev|Whatever) Ops. IT. Take your pick. OKRs. Scrum. Agile. SAFe. Force Mgmt. The latest framework/process you're deploying. Now you're trying to maximize the usage of that product/process. You want to show ROI. You create playbooks of what to do. You train everyone on it (an early warning sign is when getting people into training feels like herding cats) At some point in the conversations to discuss the adoption of the new product you feel nobody's there with you. It's like that [video of the dancing guy....](https://www.youtube.com/watch?v=GA8z7f7a2Pk) [but nobody joins](https://www.youtube.com/watch?v=GA8z7f7a2Pk) :-( It's like you've "Built it" and nobody's coming. What's going on? Here's the thing - Deploying a product or process internally is like developing a product. Yes, that product is already developed. The features/capabilities are all there, ready for your internal users to use. But the fact that a feature is there doesn't mean people want to use it. It doesn't mean they WILL use it. Even if you ask. And especially if you tell... So what do you do? See yourself as responsible for maximizing value. Not for adopting a tool. Figure out what problems to help your users with. What outcomes to focus on. If managing the adoption of an internal product/process is like managing a product... ## What can IT/Ops leaders responsible for organizations focused on deploying/adopting these products/processes learn from product management?

From Hype/FOMO/Theater to Fit-for-Purpose: How To Use a Product Operating Model To Develop Your Product Operating Model

Yuval Yeret — Tue, 15 Apr 2025 00:00:00 GMT

Alice wants her product organization to adopt a product operating model because she believes it's the future of working. She's been an early adopter of agile and lean startup methods and is constantly looking for better ways to work. Bob wants their product organization to adopt a product operating model because they have an expensive problem—they were brought in to help scale a product organization. With 12 product teams working on a line/portfolio of products, there's little consistency, little alignment to outcomes, and little predictability. Charlie heard about a product operating model from their analyst at Gortner. Then, the Partner at McLoitte, with whom they're working, suggested it might be the next big step in their organization's transformation. WDYT? Which of these product/tech leaders will get more out of their investment in adopting a product operating model? Alice is motivated by ambition. She is one of a rare breed of leaders whose ambition is oriented around the How, not the What. She knows that being proactive and creating a great organization will eventually impact her organization's results. Alice is willing to invest in improvement even if it's not directly connected to a top-of-mind, expensive problem. She's even excited to try new things for the sake of innovating. Bob is motivated by desire. They have a real problem to solve. For Bob, any work on ways of working needs to be tightly connected to top-of-mind problems/opportunities that affect the ability of their organization to deliver. Charlie is motivated by status / FOMO (Fear of missing out). If everybody is investing, they will jump on board. What should you do if you’re Alice? Bob? Charlie? How should you approach the Product Operating Model? (Or any similar opportunity? ) : Here’s what I’d do: - Explore real problems and see which improvement ideas could address them. (even and especially if the improvement idea first emerged due to FOMO or new shiny thing syndrome) - Frame an outcome hypothesis - why? Why now? - Identify leading indicators focused on the behaviors the change will drive/enable (avoid vanity metrics!) - Treat ways of working development as a “Platform Product,” applying a customer-centric approach to serve their internal customers—the product organization and the ecosystem around it. - Working with suppliers? Adopting a Product Operating Model could be a nice opportunity to move from a project-to-product mindset in how you engage your vendors… ## Or, in other words, use a product-led mindset to develop and leverage a product operating model.

The Status of Agile as a Platform and Navigating Agile Career Pivots

Yuval Yeret — Tue, 15 Apr 2025 00:00:00 GMT

What's the future of Agile? Agility? [Agile as a career choice?](/blog/the-future-of-agile-roles-the-future-of-agility) Yesterday, I joined [Jonathan Stark](https://jonathanstark.com/) on his podcast Ditching Hourly to discuss [the current state of Agile as a platform, how it has evolved over the years, and what practitioners should consider as the platform matures.](https://podcast.ditchinghourly.com/episodes/yuval-yeret-the-status-of-agile-as-a-platform-and-navigating-career-pivots) Jonathan primarily focuses on advice for freelancers/consultants on ditching hourly billing through positioning, productized services, and pricing advice. If, like me, you're a freelancer/solopreneur agile practitioner (or are considering becoming one), I'm sure you'll find Jonathan's materials interesting. (I do.) He recently published a series on [Platform Specialization](https://jonathanstark.com/daily/20250326-1737-what-is-platform-specialization), which I thought was very relevant to the Agile space. One very interesting part of the conversation was how to apply Jonathan's advice (e.g., the Why conversation) if you're an internal or employee agile practitioner trying to survive or thrive by moving from agile theater toward a more outcome-oriented, evidence-informed positioning. What are YOU doing about what's recently happening in the Agile space? https://open.spotify.com/episode/14zbBVlwWh2L4WDcIy7VFm?si=cP-mUzCjT0qcmB32Wgpvqw ## [Interested to hear more from me? I recently launched the Scaling w/ Agility Podcast. Check it out.](/yuvals-scaling-w-agility-podcast)

The Value Of The Feature Factory

Yuval Yeret — Fri, 11 Apr 2025 00:00:00 GMT

Back in 2006, calling my product delivery organization a factory would have been a compliment. We were struggling to deliver predictably. Quality was such a big issue that I joked about asking one of our QA engineers to take a vacation during our final hardening week so that we would have a chance to get through the week without additional, painful fix/test/fix/test cycles. Becoming a Feature Factory with improved flow, predictability, transparency, and quality was serious progress. Feature Factories have their place. They're a milestone on the road to becoming a Product-oriented organization. It's much harder to organize teams empowered to deliver outcomes if your teams still deliver components. It's almost impossible to steer with evidence if your teams don't continuously create working stuff that generates evidence/data. The main issue I see with Feature Factories is that organizations stay stuck with them. They see them as the goal, not a stopover. Agile/Product Theater isn't helping - it's a reality distortion field. The main benefit of the recent buzz around Product Operating Models is that they help product and technology leaders see through this reality distortion field. We should help product and tech leaders pursue becoming a product-oriented organization that is empowered to seek towards customer outcomes. What we shouldn't do is disrespect the journey that got us here. Yes, you could argue that we should have moved from the feature factory straight to a product lab. But what about incremental change? Iterating? Inspecting and adapting? Most organizations needed the Feature Factory stopover. ## Now we need to get together and help them take the next step (rather than fight the Agile vs Product wars).

Product-Led AI: How to Turn LLM Geekery Into Customer Outcomes

Yuval Yeret — Thu, 10 Apr 2025 00:00:00 GMT

Engineers excited about LLMs, Agentic AI, RAGs, spending time going to the vendors, playing around like kids with new toys. Without a real problem in mind. Without the ability to deploy any of it in the organization (the engineers don't talk to the legal folks much...) Can you think of where so much time and energy is spent on a technical innovation without connecting it to a real problem? Of course you can... Mobile, Cloud, Big Data, just to think of a couple of recent examples. To be honest, I can't think of a significant technology wave WITHOUT this cart-before-the-horse behavior. This is an example of tech/engineering-led behavior. What would Product-led look like? Here is a non-comprehensive starting point to consider... - Align around the customer outcomes we're hoping GenAI will serve—e.g., improving the Developer Experience, the Shopper Experience, or the Fraud Detection Officer Experience. - Empower the team to deliver outcomes - if Legal is a major issue for deploying AI, have someone on the team who understands their perspective and is ideally empowered to make some decisions. If Security/Risk is an issue, have someone from Cybersecurity on the team. Localize dependencies so that the team can try real things fast. - Explore the problem/opportunity space - what are the biggest friction points/bottlenecks in the current experience/process that need solving? How are you approaching your GenAI efforts? What might it look like to apply a product mindset, orientation, and operating model to developing your AI capabilities, **even when they have nothing to do with your products?**

SAFe-ly Scaling an Agile Product Operating Model

Yuval Yeret — Fri, 04 Apr 2025 00:00:00 GMT

How can an Agile Product Operating Model (APOM) enhance how organizations use SAFe? I had several conversations with product leaders this week where this question came up. Organizations that are struggling with SAFe Theater and want to see much more empowerment, outcome orientation, and evidence-driven decision making and steering. They realize SAFe has helped them evolve from charos towards a stable "Feature Factory", and they are now setting their aim for becoming a "Product Lab". If this sounds like your reality you might find my [recent conversation with Scrum.org CEO Dave West interesting.](https://www.scrum.org/resources/agile-product-operating-model-apom-and-safe-do-they-relate) Check it out: https://open.spotify.com/episode/2ygn2oxE0U7UhKnd5xA8o0?si=Ms5y5cjYT3OJ2U-jbnHGYw In related news, Scaled Agile released an [Executive Briefing about the Product Operating Model At Scale](https://scaledagile.com/resources/product-operating-model-executivebrief/), which is worthwhile reading as well. Let me know if you'd like me to facilitate a live Q&A discussing this briefing. ## [![](/assets/images/blog/image-6-1024x629.png)](https://scaledagile.com/resources/product-operating-model-executivebrief/)

Sniffing your Product Orientation Maturity using Team Names

Yuval Yeret — Thu, 03 Apr 2025 00:00:00 GMT

**Persistence Pioneers** **UI Architects** **Embedding Engineers** **Refactor Rebels** **Sprint Sprinters** **Integration Innovators** **Audio Overview Creators** **Mind Map Builders** **YouTube Insights Team** **Scalability Savants** **Podcast Summarization Squad** **Knowledge Connectors** Can you guess which product these teams are working on? Which of these team names helped you more than others? Let's say your organization has more "UI Architects" or "Persistence Pioneers" than "Knowledge Connectors" or "Youtube Insights". What does it mean about your [Product Pyramid?](/blog/when-and-why-do-we-need-a-product-operating-model) **Here's a party trick for you:** Want a quick sniff test to determine whether your teams are empowered to focus on and deliver outcomes? Look at their names. ## (Still wondering which Product these teams are working on? NotebookLM)

When and Why You Need a Product Operating Model

Yuval Yeret — Wed, 02 Apr 2025 00:00:00 GMT

You found product-market fit. You scaled by hiring great product people and the best engineers. You're using agile ways of working. So why is it harder to ship a simple feature today than it was when you were 50 people? > ### 💡 Insight: The Coordination Tax > > Most organizations scale by adding 'alignment layers' (PMOs, sync meetings). This is a tax on your speed. True scale comes from _eliminating_ dependencies, not managing them. You’re not alone. Many teams start strong, laser-focused on delivering value. But as success scales, dependencies pile up, alignment fades, and the startup days' speed and impact are gone. It's become a major risk to continued growth. ## Why Do Product Organizations Stall? Here’s the typical lifecycle: - **Early Days**: One team, minimal dependencies, clear goals. It’s all about finding product-market fit and delivering value fast. - **Growth Phase**: Demand grows, teams specialize, and suddenly alignment becomes a challenge. Conversations shift from outcomes to scope and timelines. - **Scaling Chaos**: Multiple products and cross-company initiatives create sprawling dependencies. Work devolves into projects managed with traditional methods. The result? Fewer empowered teams, more inefficiencies, and a lot of frustration. Right now, your organization is inverted. You have 10% of your teams delivering value, and 90% of your teams managing 'coordination tax.' You are paying senior engineers to sit in alignment meetings instead of building product. ## Flipping the Pyramid We need to stop managing dependencies and start eliminating them. We flip the pyramid to restore **flow**: 1. **Empowered Product Teams**: The foundation. These teams own outcomes and operate autonomously. We want to move as much work as possible into such teams by changing product topology, team structure, or architecture. 2. **Product Groups**: For work that spans multiple teams but can still be managed within a focused group. Use when you can't create a single empowered team or want to encourage synergies. 3. **Strategic Initiatives**: A small set of cross-organizational efforts managed with flow principles—focused on outcomes, evidence-driven, and limited in scope. ![](/assets/images/blog/image-3-1024x461.png) ## The Roadmap to Change A Product Operating Model isn’t just another reorg—it's mainly about behavior, decision rights, and flow. Structure can support it, but behavior creates outcomes. Transforming requires: - Aligning on strategic goals and priorities. If you are overloaded, start by actively limiting the amount of work pulled into the higher levels of the pyramid. - Using the healthy pyramid as a north star for architectural changes to detangle products. - Building platforms and enabling teams to support empowered teams. - Managing the balance between team autonomy and organizational alignment. You can usually feel meaningful improvement—early signal shifts—in a quarter when leadership tackles the top systemic constraints. Full operating model maturation is iterative. ## Why It Matters A flipped pyramid means less micromanagement and a clearer path to delivering real value. If you have more engineers than ever but less speed and impact, adding more process won't fix it. --- _If you want to operationalize this, see my [Product Operating Model Playbook](/blog/how-to-develop-your-product-operating-model-playbook/) or explore [Strategic Agility advisory](/work-with-me/figure-out-your-product-operating-model-strategy/)._

What Do Trusted Peer Groups Have to Do with Scaling Agility? (Podcast)

Yuval Yeret — Mon, 31 Mar 2025 00:00:00 GMT

Leading an agility journey can often feel lonely. These days, especially, there's plenty of complexity, and rapid change—what we’ve come to know as VUCA (Volatile, Uncertain, Complex, Ambiguous) or even the newer BANI framework (Brittle, Anxious, Nonlinear, Incomprehensible). Building and growing a consulting/advisory business in the agility/product/scaling field also provides plenty of VUCA and BANI. Peer groups, like Masterminds or the Forums used in the Entrepreneur Org (EO) / Young Presidents Org (YPO) / Vistage, offer an interesting approach to supporting individuals navigating these challenges. Last year, I took the time to explore the Peer Group concept in more depth, exploring how it can help me serve leaders on their agility journey. I connected with Mo Fathelbab, who founded the International Facilitators Organization (IFO), and became an IFO Facilitator. **Why Peer Groups for Leaders Navigating the Frontiers of Agility?** With their emphasis on empathy, vulnerability, confidentiality, and sharing experiences rather than prescribing advice, here's why I'm thinking this might be interesting in our world: - You want to steer your ship but also crave meaningful feedback from peers who understand your challenges. - You need a safe space to share wins, struggles, and ideas without judgment or competition. - You benefit from learning through others’ experiences rather than theoretical advice. If this approach resonates, I encourage you to check out my [recent conversation with Mo on *The Heart of Business*](https://www.buzzsprout.com/2238229/episodes/16866430). In it, I share my journey toward becoming an IFO facilitator and how peer groups have influenced my thinking about leadership and collaboration. [![](/assets/images/blog/archive/Podcast Cover_large.jpg)](https://www.buzzsprout.com/2238229/episodes/16866430) Here's what Mo and I explored on the podcast: - **Learn from My Journey:** Hear how I transitioned from tweaking computer systems to transforming organizational systems, blending technical expertise with human dynamics. - **Build Trust in Leadership Teams:** Discover how vulnerability-based trust can strengthen decision-making and foster open, productive conversations. - **Embrace Flexibility with Trail Maps:** Find out why I advocate for "trail maps" over rigid roadmaps to empower teams and navigate uncertainty effectively. - **The Power of Shared Experiences:** Understand why sharing personal experiences, rather than giving advice, helps preserve autonomy and fosters growth. - **Unlock Agency in Your Organization:** Explore the importance of creating structures that enable autonomy and mastery for individuals and teams. - **Reconnect Through Human Moments:** Learn why I believe in the value of building connections through shared meals and in-person interactions, even in a remote-first world. - **Join My Vision for Peer Groups:** Get inspired by my plans to create peer groups where leaders can share experiences, tackle challenges, and grow together. - **Navigate Change with Confidence:** Hear my approach to helping organizations adapt to large-scale transformations like agile or AI integration. [Listen To The Heart of Business Podcast](https://www.buzzsprout.com/2238229/episodes/16866430) ---

How to Implement a Product Operating Model (Playbook Guide)

Yuval Yeret — Fri, 28 Mar 2025 00:00:00 GMT

_Guest post by [Vered Yeret](https://www.linkedin.com/in/veredyeret/). This guide shares Vered's approach to designing and rolling out a Product Operating Model playbook in a practical, iterative way._ If you need the strategic context first, start with [When and Why You Need a Product Operating Model](/blog/when-and-why-do-we-need-a-product-operating-model/). This page focuses on implementation. A Product playbook is a repository of best practices, processes, and tools that streamline product management. It ensures that products meet customer expectations and drive business growth. This document suggests an approach for building such a playbook. Of course, the content will vary based on the organization's culture, structure, stakeholders, and needs. This playbook can be considered a product serving the Product Organization and the Company. With that in mind, here is an approach for developing it using product techniques. This includes being customer-centric (the Product professionals being the customers), involving relevant stakeholders, and iteratively discovering and delivering increments of the playbook to delight Product Professionals and help them do better product work. ## Start with the Why? Define Purpose & Goals Review and agree with stakeholders on the goals and outcomes of this playbook: 1. Align product management processes for consistency, efficiency, and cross-functional collaboration. 2. Enhance decision-making and communication across the company's product teams. 3. Leverage this playbook to help onboard new PMs and ensure they clearly understand processes, tools, and expectations. 4. Serve as a guiding framework for consistent product excellence, communication, and collaboration at the Product Organization. ## Who needs to be involved? Identify Key Collaborators 1. **Product Management**: Heads of Product, Senior PMs, Product Owners. They typically own the playbook itself, but it must be a collaborative effort. 2. **Engineering & Design**: Tech Leads, UX/UI Designers, QA Leads. 3. **Customer-Facing Teams**: CSMs, Sales, Support. 4. **Product Marketing**: Product Marketing Managers ensure product features and market positioning alignment. 5. **Data & Analytics**: Analysts providing metrics & insights. 6. **Operations & Enablement**: Project Managers, RevOps. ## How to gather data? Collaboration Structure 1. **Establish a Single Source of Truth**: Use a collaboration tool like Notion, Confluence, or Miro for asynchronous collaboration and documentation. This is the central hub where all inputs, insights, and templates are collected and refined. 2. **Workshops**: Cross-functional sessions to gather insights and identify gaps. 3. **Focus Groups**: Deep dives into specific areas (e.g., Roadmapping, Discovery, Decision Making, Prioritization, Launch). 4. **1-on-1 Interviews:** Senior stakeholders for detailed feedback. 5. **Surveys:** Broader quantitative input. ## Create a Steering Committee 1. Key group representatives will guide and champion the playbook and ensure company strategy alignment. 2. Establish regular check-ins for feedback and course corrections. ## Key Components of a Product Management Playbook 1. **Product Vision & Strategy:** Defining, documenting, and communicating the company's product vision and strategic objectives, and how to align it to the company’s strategy. 2. **Product Development Lifecycle:** Clearly defined stages from discovery, planning, development, launch, and post-launch. 3. **Roadmapping & Prioritization:** Frameworks and tools for prioritizing features, initiatives, and setting timelines. 4. **Decision-Making Frameworks:** Guidelines for making trade-offs and ensuring alignment with strategic goals. 5. **Stakeholder Management:** Best practices for communication, collaboration, and reporting. 6. **Metrics & Measurement:** Clear metrics to measure success, track progress, and continuously improve. 7. **Using Agile & Lean Methodologies:** How to leverage agile and lean principles for iterative development, faster feedback loops, steering with evidence, and reducing waste. 8. **Encouraging a Customer-Centric Mindset:** Ensuring product decisions are driven by customer needs, insights, and feedback throughout the product lifecycle. 9. **Onboarding & Training:** A standardized process to onboard new PMs and get them up to speed quickly. ## Develop the Playbook Iteratively (Like a Product…) 1. **Discovery & Research:** Map existing processes & pain points. 2. **Prioritize** high-impact opportunities and **Select** one improvement area at a time. Don't try to boil the ocean. Capture core principles, decision rules, and key workflows first, then iterate based on adoption and friction points. 3. Focus on a **Clear Outcome-based Goal** 1. Define clear KPIs: Adoption Rate, Satisfaction Scores, Onboarding Success, as well as leading outcome indicators. 4. **Learn from High-Performing PMs/Teams internally and externally:** 1. Gather Insights: Interview high-performing PMs and cross-functional stakeholders to understand what works best. 2. Observe High-Performing Teams: Shadow top-performing PMs and teams during planning sessions, roadmap reviews, and retrospectives to identify effective practices. 3. Adopt and integrate: Incorporate effective frameworks, road mapping techniques, prioritization methods, and feedback loops from top performers. 5. **Draft Framework:** Create outlines for Processes, Roles, and Tools sections. 6. **Test & Refine:** Build and refine templates with stakeholder feedback. 7. **Communicate and Rollout:** Deploy and enable the wider product organization. 1. Announce the initiative via various communication methods: Slack, Email, and Town Halls. 2. Provide regular updates & host training sessions. 3. Ensure easy access to the playbook. 4. Create a feedback mechanism for continuous improvement. Tie the playbook to regular planning and review cadences to keep it from becoming shelfware. 8. **Review and Adapt:** 1. Measure adoption and impact. 2. Continuous improvement through feedback loops until the desired outcomes are achieved. ## Final Thoughts In this playbook we outlined a product-oriented approach for building a product playbook—also known as a product operating model. Using this approach, a Product organization can take pragmatic, nuanced increments towards improving how it operates. This allows organizations to scale with consistency, adapt to dramatic changes (e.g. GenAI adoption), and continuously improve the Product Management experience in a way that is sustainable, collaborative, and impactful. If you want help applying this in your own organization, I offer a [Figure Out Your Product Operating Model Strategy Workshop](/work-with-me/figure-out-your-product-operating-model-strategy/) as well as an [advisory service oriented around building and evolving your Product Operations capability "as a product"](/work-with-me/bring-clarity-and-traction-to-your-product-organization-with-product-operations).

Accelerating Without Losing Grip: The Power of Organizational Traction

Yuval Yeret — Tue, 25 Mar 2025 00:00:00 GMT

A CEO asked me last week why I'm using the term [Organizational Traction](/mastering-organizational-traction-trail-map). I got the inspiration from _Traction: Get a Grip on Your Business (\_Gino Wickman's book introducing EOS - [here's my take on it from a while ago](/blog/entrepreneurial-operating-system-traction-how-does-it-relate-to-agile-scrum)). Here's how I explained it in the conversation yesterday: _Imagine you established a strategic vision. You know where you're going._ _But it seems like there's no progress towards this vision._ _It's like full gas in neutral._ _Trying to get a grip in the mud._ _Or losing grip in a tight corner._ _Or your tires are worn out. Or its time to change to winter tires._ **Company operating systems like EOS, OKRs, Scaling Up, and Scrum are designed to improve traction.** It's not about activity. It's not even about outputs. It's about outcomes and evidence of moving in the right direction at a good speed. I started using traction instead of progress in my work with product organizations and company leadership teams. I find it is a better fit when trying to evolve from projects to products, from activity and output to outcomes. If you want to dive deeper, I discuss a few of these company operating systems and explore accelerating without losing traction in the [Mastering Organizational Traction email course](/mastering-organizational-traction-trail-map). Are you using EOS? Scaling Up? OKRs? Are they helping you maintain/improve traction? [Let's discuss]({{DISCOVERY_URL}})

Product-Led vs Service-Led: PLG, Product-Led Org, and Product Operating Model

Yuval Yeret — Tue, 25 Mar 2025 00:00:00 GMT

I see some practitioners and leaders using these terms interchangeably. I thought I'd take the time to clarify the overlaps and differences, first of all for myself. **Product-Led Organization**—As opposed to Sales, Engineering, or Marketing-led organizations, a Product-Led organization is structured to deliver value through the product. These organizations often have product-oriented leaders at the helm. Examples include Tesla, Spotify, and Atlassian. **Product Operating Model** (POM)—This is about how the product/engineering organization operates. It typically entails empowered product teams aligned and steering toward customer outcomes. It has gained popularity as more organizations move from project factories toward a product focus. **Product-led growth** (PLG)—A go-to-market strategy where the product itself is the leading mechanism for acquiring customers. Think Slack, Dropbox, Zoom, or Canva—utilizing freemium models and viral loops. **What's the relationship between these three terms?** A company could be a Product-led Organization, leverage a Product Operating Model, and rely on a PLG motion. It could also do each one of these or any mix. A Product Operating Model thrives in a Product-led Organization, but it is an uphill battle in a Sales- or Marketing-led environment. It is almost essential if you're trying to build a PLG motion because it's so product-centric. I'm having a headache imagining an organization trying to achieve PLG without it. **What's the relationship between a Product Operating Model and Agile?** It's tough to discern "Awesome Agile" from a Product Operating Model. I'm not talking about the theater or rituals here. I'm talking about the principles used to design the organization and run it. --- _If this distinction matters in your current strategy work, explore the [Product Operating Model advisory path](/work-with-me/figure-out-your-product-operating-model-strategy/) to discuss your context._

How To Start A Conversation About Agility

Yuval Yeret — Mon, 24 Mar 2025 00:00:00 GMT

## "Can we just start with day 2? (Fast forward the WHY/WHAT)" If only I had a dollar for every time I heard this statement in an agile workshop (and was smart enough to invest in NVDA at the time...) Even before we became addicted to short-form content, we never had the patience for the history lesson that most of these agile workshops started with. Workshops morphed to spend more time on practices and less time on principles. A side effect of this widespread focus on the HOW is that more and more practitioners and leaders are think they don't need workshops or formal training anymore. They can learn the HOW on their own, from a book, from AI, or from free videos. The result? Whether it's due to shallow HOW-focused training and materials or just skipping the training, We're seeing people who practice without understanding the WHAT and the WHY. Without a solid grasp on the Intent, It is hard to adapt to the context. The other extreme is also far from ideal. The whole "Agile is Dead" movement is "throwing the baby out with the bathwater" (what Ron Jeffries called ["We tried $baseball$ and it didn't work"](https://ronjeffries.com/xprog/articles/jatbaseball/) - replace $baseball$ with XP, Scrum, SAFe, POM) ## What's an alternative to focusing on the HOW? Here's what how I bring both Principles and Practices together, in a way that is intent-driven and context-aware. It starts with getting the organization [unstuck](/work-with-me/fixing-your-agility) (whether already "using" Agile or not). I often start with this exercise: - Create an applicability/maturity matrix (see image) ![](/assets/images/blog/image-4.png) - Populate with principles or practices you're considering. (I have a list [here](/principle-based-agility-assessment) I often use, but it could also be the SAFe principles, Agile Manifesto principles, XP principles, or whatever you fancy) - Facilitate a conversation about applicability/fit, ranging from "fit like a glove to our world" to "why the heck would this work for us?" This can drive interesting conversations. - Similar - for "Where are we?" (maturity) - this is more about whether we are leveraging this principle/practice right now. if not, what would need to be true to leverage it? - It's helpful to start with applicability and only then talk about current state - because we're already in the mindset of which principles will be helpful. (also - you can skip the principles you don't think will be helpful ) You could do this on your own for self-reflection or together with colleagues. (Having some [external expertise](/work-with-me/fixing-your-agility) to challenge your assumptions doesn't hurt...) In my experience, after identifying what principles will be beneficial, exploring the practices/patterns available to instantiate these principles is a much healthier, fruitful conversation. PS My focus on Enterprise Kanban and, later on, [Portfolio Agility](/the-portfolio-agility-trail-map) emerged after seeing how often traditional portfolio-level processes/behaviors/metrics are lurking under the surface, inhibiting the agility of these organizations I was trying to help.

What is the difference between Scaled Agile/SAFe and a Product Operating Model? (Interview on the Business Agility Now Podcast)

Yuval Yeret — Fri, 21 Mar 2025 00:00:00 GMT

I recently joined Adam Mattis on the "Business Agility Now" podcast for a conversation about scaling agile and product operating models. It's always a pleasure to chat with Adam about the realities of applying agility at scale and some of the trends I'm seeing in the field. We covered various topics, drawing from our experiences helping organizations navigate the complexities of business agility in a variety of environments. Here are some of the **key themes and topics** we focused on: **The Enduring Principles of Product Management:** We explored the idea that while applying technology to product management is relatively new, the core discipline itself has deep roots in consumer goods industries. **The Growing Awareness of Product Orientation:** Organizations who initially focused solely on agile project management are now recognizing the critical need to become genuinely product-oriented to achieve desired business outcomes. **Product Ownership vs. Product Management:** We delved into the differences between these roles, drawing parallels with category management and product line management in consumer goods. **The Challenges of Centralized Decision-Making:** We discussed how, in many enterprises, true decision-making authority often resides far above the designated product managers and product owners, leading to the "feature scribe" phenomenon. **The "Backlog Owner" Reality:** We touched on the fact that many individuals with the title of "product owner" are essentially backlog managers without true product ownership responsibilities. **The Buzz Around the Product Operating Model (POM):** We explored the emerging conversations around product operating models, considering whether they represent genuine shifts in perspective or just new terminology for old problems. We highlighted that an **emphasis on empowered product teams and steering with evidence** are key aspects of a POM . **SAFe and Product Orientation:** We discussed how a strong foundation in agility (using frameworks like Scrum/SAFe) is crucial for a successful product-oriented approach. There's a real opportunity to use the product-oriented movement to re-emphasize core agile and SAFe principles like focusing on objectives and outcomes in PI Planning. **The Foundational Prerequisites for Product Centricity:** We agreed that before organizations can truly embrace a product-centric view, they need to establish strong foundations in areas like DevOps, CI/CD, clear product definitions, and aligned teams. **The Power of Product-Oriented Portfolio Conversations:** Shifting the focus at the portfolio level from managing a book of work to emphasizing outcome-oriented strategic themes and leading indicators can be game-changing. **The Critical Role of Incentives:** We underscored the point that to truly become product-centric, organizations need to align their incentive structures to reward product performance rather than just project outputs. **The Consultant as an "Interventionist":** We had an interesting exchange about the role of consultants, with Adam coining the term "Enterprise Interventionist". We emphasized the importance of providing appropriate interventions and even having the courage to say "no" when the conditions for success aren't there. **The Potential Synergy Between SAFe and POM:** I shared my belief and experience in the trenches that SAFe and the Product Operating Model aren't in conflict but can complement each other, with SAFe providing the structure for execution that POM needs. Throughout our conversation, we emphasized the need to move beyond just adopting new terms and to focus on the hard work required to create truly product-oriented organizations that deliver tangible business value. If you're interested in these topics and want to hear our full discussion, I encourage you to **[listen to the entire podcast episode](https://scaledagile.com/podcast/safe-and-product-management/)** or watch it on [Youtube](https://www.youtube.com/watch?v=ZxYcIrsT0Yw). As a follow-up to these ideas, I recently released a free email course called the ["Portfolio Agility Trail Map."](/the-portfolio-agility-trail-map) It offers insights and tips for those looking to make their scaled agile organizations / portfolios more product-oriented. If you'd like to explore this further, check it out. I'd love to hear your thoughts on these topics! Feel free to connect and share your experiences. https://www.youtube.com/watch?v=ZxYcIrsT0Yw&feature=youtu.be _Questions about scaling agility, Kanban, or organizational transformation? [Explore advisory options](/work-with-me) or [let's talk](/work-with-me)._

Mastering Organizational Traction Or Portfolio Agility?

Yuval Yeret — Mon, 10 Mar 2025 00:00:00 GMT

Should you focus on mastering organizational traction or on establishing portfolio agility? Let me tell you a secret: In my experience, mastering organization traction involves realizing you have a portfolio of investments you're managing. So actually the paths converge... The difference is that mastering **organizational** traction extends beyond the IT/Product world. It intercepts business initiatives before becoming mandates for the technology organization. It also manages non-digital developmental work (yes - some of that still exists!) When people ask me which email course I should take—Mastering Organizational Traction or Product-oriented Portfolio Agility—I ask them about their context. ![](/assets/images/blog/image-3-1024x467.png) If they're a product/tech leader trying to apply a product operating model in a multi-product context - I suggest the [Product-Oriented Portfolio Agility Trail Map](/the-portfolio-agility-trail-map). If they're a chief of staff, CXO, or even a Product/Tech leader trying to work through a scaling up inflection point, [Mastering Organization Traction](/mastering-organizational-traction-trail-map) is often a better starting point. If you want help deciding where to start, see [Portfolio Agility](/work-with-me/portfolio-agility/) and [Create a Business-level Operating System leveraging Agility](/work-with-me/create-a-business-level-operating-system-leveraging-agility/).

When is Agile worth the Overhead?

Yuval Yeret — Fri, 07 Mar 2025 00:00:00 GMT

_“Agile is so great we need to use it for EVERYTHING”_ *“Agile is so much overhead, we stopped using it for ANYTHING”* *Are you also trying to navigate what to do with Agile? Whether it’s worth the overhead?* After years of helping a diverse group of organizations figure out where and how to use agile methods, here's what I've learned... If you want the TL;DR version - Agile has the **potential to shine** when …. 1. There’s enough [risk and uncertainty](/blog/risk-aware-product-development-a-k-a-agile-2) to justify the overhead of frequent feedback loops. 2. Addressing the challenge/leveraging the opportunity requires collaboration - sometimes across functions. 3. You focus on [principles/behaviors](/principle-based-agility-assessment) rather than [mechanics/dogma](/blog/the-agile-theater) What this also means is that in the **absence of the need for iterative collaborative work,** no matter how streamlined and effective your agile process is, **it might not be worth the time!** ## Diving Deeper You can think of it as a two by two chart with an axis for type of work (routine/operational vs innovative/developmental) and the other for level of collaboration needed (individual vs collaborative, sometimes cross-functionally) | | **Individual/ Functional / Siloed** | **Cross-Functional / Systemic** | | ------------------------------ | ---------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Innovative / Developmental** | Introducing new IT capabilities Conversion Funnel Optimization Paid Ads & Growth Experiments | Improving the Customer Experience Introducing and optimizing revenue generation motions Developing new products and features, and finding Product-Market-Fit Improving the onboarding experience Creating an amazing employee experience | | **Routine / Operational** | Solving IT issues (IT Helpdesk) Maintaining products Generating Revenue (using established motions) | Ensuring Customer Success Talent Acquisition Generating Revenue (complex enterprise ABM) | ## Cross-functional / Collaborative Bets Developing new products and getting to Product-Market Fit is an easy example—there’s plenty of risk/uncertainty combined with the need for collaboration across product management, development, and often go-to-market functions. This is why working in an agile manner is a given for new product development (note including GTM in the loop is less of a given…) And why more and more leaders and organizations are leveraging agile/agility patterns for other cross-functional developmental/innovative work. Developing capabilities that grow/transform the organization often land in this quadrant as well - think of it as Developing the organization like a product. A trendy current example (Circa 2025 at least ) is figuring out how GenAI capabilities can help the organization scale. GenAI could also help reduce the collaboration needed and enable smaller, faster teams to cover a wider area of skills/responsibilities. ## Individual Routine/Operational Work There’s almost no need for feedback, so iterative approaches don’t make much sense. Managing flow can be helpful in avoiding overload, improving focus, etc. This is where techniques such as Getting Things Done (GTD), Personal Kanban, Pomodoro can be helpful. This work is also where automation can make a big impact—it can help the same group of people get more work done, which is useful when trying to improve margins as you scale. The developmental work from the top right quadrant often aims to improve this work. AI Agents can help take over work that requires monitoring/reacting and only involve humans when needed, which fits well here. For example, it could automate some of the SDR work—enriching incoming leads and drafting personalized nurture sequences—or help recruiters nurture candidates in a thoughtful yet compliant manner. ## Collaborative Routine/Operational Work Most organizations want multiple people to interview a candidate and exchange notes as part of the talent acquisition process. Still, a hiring committee does not necessarily address a complex problem (but sometimes it does! e.g., when working on a new type of role, shifting needs, etc.). Visualizing and managing flow can be useful here as well. Techniques like a Kanban board for the entire “value stream” (e.g. candidate journey) are worth considering. Automation and AI can also be helpful here, e.g., by consolidating hiring committee notes and suggesting key points for a live conversation. Although the work is routine, it is still helpful to improve it. So some debrief/retrospection on a cadence or at the end of a certain batch of work can be helpful. You can think of this aspect as a bridge between the routine operational work and “developing the organization like a product” work. ## Individual Bets Beyond flow, the concepts of outcome orientation and empiricism are useful here. Even if no team/collaboration is needed, it still makes sense to derisk through experimentation and maintain optionality through focus on outcomes. Individuals should still consider navigating the truth curve—looking for the cheapest way to learn and steer before committing too much time to a bet. ## It’s all about Intent, Context, and Choice Here’s the thing. Applying a cookie cutter approach for everything might seem more straightforward and more consistent, but creates two significant issues: 1. If it’s not a good fit, it will require much more energy to get going. It will be an uphill battle, and it is often the start of a reinforcing downward spiral of the whole approach. 2. Even if it can be a good fit, forcing people to use it removes their choice. People don’t resist change; they resist being changed. In my experience, aligning on the intent, exploring the context variables that affect relevance, and finally giving people the choice when/where to apply a new technique/approach creates dramatically different results. ## Here’s a quick reflection challenge for you: 1. What’s one area in your organization where you should STOP leveraging agile ways of working? 2. What’s one area where you can leverage more agile ways of working, that you haven’t thought of until now? 3. What’s one small thing you can do to give people more choice in approaching agile in your organization? --- _Moving from agile theater to real business agility takes more than a framework. [Explore Business Agility advisory](/work-with-me) or [let's talk](/work-with-me)._

Scaling Companies Up Requires Some of The Startup Phase Scrappiness

Yuval Yeret — Mon, 03 Mar 2025 00:00:00 GMT

Founders know that scaling their company to Unicorn status requires extending beyond a singular focus. Launching a product extension. Complementing your established Go-to-market motion. Entering new markets (Different ICP, Geography, etc. ) **Often, companies approach these extensions using the same processes they use for their established Products/Markets.** They approach a new product opportunity with unwarranted conviction. They go into a new market using established/scaled revenue operations. They implement new motions using "big design up front" They often spread too thin by working on multiple extensions simultaneously. They work on them using the same processes and structures that are tuned for "efficiency" and "margin expansion" That often turns out to be an expensive mistake. **Because unlike your established Product/Market, these extensions are often bets.** They often require multiple departments to collaborate tightly to find the extension's Product-Market-Motion Fit. They require an experimentation mindset (like the same company had in its pre-PMF days...) Whether it's new leaders brought in to "scale" the company, or the same leaders who were around during the initial leaner days, **running a dual operating system - efficient and scrappy side by side - is hard.** I find it helpful to be explicit about your portfolio of activities - which can benefit from efficiency-focused operating systems, and need agile scrappiness. Here's one technique that can help you[ improve organizational traction ](/mastering-organizational-traction-trail-map)on these strategic bets: - Reflect on your goals (e.g. OKRs or items on your [company Kanban board](/blog/lets-open-the-portfolio-kanban-cards)) - Categorize them based on the level of bet they represent - Decide what the right operating model is for them - Scrappy or Efficient? - Manage the riskier Bets like VCs manage their startup portfolio ## NOTE: This post is inspired by a [Science of Selling Podcast episode on Extending to Multi-Product Selling](https://open.spotify.com/episode/2Ohe1FPTunWwYcY8pQnRQj?si=PYbmh8d5S7SRT4ibFq2Rzw).

How To Choose An Owner For a Cross-Organization Initiative

Yuval Yeret — Tue, 25 Feb 2025 00:00:00 GMT

Reader Kevin had this question about [Cross-Product Initiative Ownership](https://preview.convertkit-mail2.com/click/dpheh0hzhm/aHR0cHM6Ly95dXZhbHllcmV0LmNvbS9ibG9nL3BvcnRmb2xpby1hZ2lsaXR5L21pc3VuZGVyc3Rvb2QtYW5kLWVmZmVjdGl2ZS1pbml0aWF0aXZlLW93bmVyc2hpcC1mb3ItY3Jvc3MtcHJvZHVjdC1pbml0aWF0aXZlcy8=): *"How should we choose an Initiative (or Epic) Owner when multiple parts of the organization will be responsible for delivery?"* That is a good question that often comes up in the trenches when I'm helping organizations apply product-oriented agile thinking to cross-organization initiatives. Here's how I think about it: Initiative Ownership is about the Why and the What more than the How. **Ask yourself - who is the best person to:** - Act as a visionary for their strategic initiative. - Own the Outcomes - Connect to customers - Collaborate with a multitude of teams on finding creative and effective ways to test and deliver outcomes. - Make critical decisions and decentralize when possible while providing clarity and context. - Focus on the risks/uncertainties and create discovery and delivery plans that provide ample opportunity to inspect, adapt, or stop. - Leverage influence to drive collaboration towards outcomes across multiple products and departments. Want a shortcut? Cross-product initiatives often have a "lead" organization closest to the outcomes we're trying to unlock. The Initiative Owner often comes from that organization. Even if other teams have more work to enable/deliver the desired outcomes. PS I've spent quite a bit of time in recent months training and coaching Initiative/Epic Owners on moving from project/delivery focus to product and evidence-based thinking. If that sounds interesting, [let's chat...]({{DISCOVERY_URL}}) For hands-on support building this capability, see [Portfolio Agility](/work-with-me/portfolio-agility/).

What Do You Do When OKRs Become Too Much Administrative Work?

Yuval Yeret — Fri, 14 Feb 2025 00:00:00 GMT

Does it ever feel like OKRs are too much overhead? Does it make sense that OKRs will only work when _"We we will have more people to manage them"?_ Let's be honest - OKRs can sometimes feel a bit heavy: - It takes time to draft them (especially if you're trying to capture everything via OKRs...) - It takes time to align (especially if you're driving them top-down, relying on large single-track meetings to converge, and are structured in a way where most strategic objectives hit many teams) - It takes time to manage / track (again, especially if you have many OKRs spanning significant cross-sections of the organization) If you're tempted to hire a PMO to manage your OKRs because they've become too much for your Chief of Staff to tackle, it's a major warning sign. So what's the alternative? One approach you can try is to go very lightweight. Whatever the company goals are, capture them. Don't spend time on wordsmithing and outcome orientation (for now) Start a kanban board to manage progress/traction on these goals. Don't try to manage all work via OKRs - just strategic guidance beyond the whirlwind. If there's a strategic initiative that cuts across too many functions and requires "project management" consider a lightweight agile approach like Scrum to manage it. No need for dedicated agile roles, but somebody should be identified as the owner of steering toward the desired outcome and there should be clarity on who's involved in this initiative and has dedicated capacity for it. Be very careful when letting people be involved in multiple such strategic initiatives. Limit the number of initiatives in progress if they all hit the same people. Here's the thing—some of the administrative overhead that OKRs bring can be avoided by adhering to the principles and being careful with the process BS. Some of it isn't really OKR administrative overhead—it's just growing pains. It's a sign that you're approaching an inflection point and need to make some tough decisions about your organizational topology. You don't have to use OKRs, EOS, or Scrum. But if you do want to scale up, you will need to figure out how to enable aligned autonomy. (I'm curious - if you used OKRs and have now switched to another operating system - what did you switch to? How is it different? ) ## Before you go, [Mastering Organizational Traction Trail Map](/mastering-organizational-traction-trail-map) is a free email course in which I help you chart a course toward better Focus and Traction.

How To Shift from Project to Product at the Portfolio level - A Scrum.org Community Q&A Podcast

Yuval Yeret — Thu, 13 Feb 2025 00:00:00 GMT

A major focus for me these days is helping Leaders who set out to shift their organizations from a project to a product mindset figure out how to scale product orientation to a multi-product environment. They want to apply product thinking to their strategic initiatives that cut across products and beyond the product organization. This is what we refer to as Product Portfolio Management. A few weeks ago, I joined Dave West and Darrell Fernandes on the Scrum.org Community Podcast to help answer key questions about Agile product portfolio management from a recent webinar. In the conversation we: - Chart a path toward a product-oriented portfolio operating model ([What I also explore in the Product Portfolio Agility Trail Map](/the-portfolio-agility-trail-map)) - Discuss the shifting role of quarterly business reviews - Explore aligning initiatives with strategic goals - Talk about how to leverage Kanban and Evidence-Based Management to manage and steer your strategic investments. [Listen to the Podcast](https://open.spotify.com/episode/2SqI2paXt5xTtQbNcAPE44?si=uGHbWIc0Q5aVbltEGgfNrA) (and stay tuned for Part 2!) ##

How Can We Nudge a Product Team To Be More Flexible?

Yuval Yeret — Wed, 12 Feb 2025 00:00:00 GMT

What do you do when a product team's capabilities aren't aligned with strategic priorities? This is a common challenge for product/portfolio leaders. On the one hand - a product-oriented operating model talks about empowered, stable product teams. On the other hand - we want to focus on maximizing outcomes. What if a product is good enough? How would we even know? And how would we know [whether we have a flexibility/alignment issue?](/blog/is-your-safe-agile-release-train-flexible-enough) Because this is such a tough predicament, in many cases, the organizational anti-bodies do their best to hide the issue. Feature Factories are a great way to do that. A team could always find features to work on. Taking the conversation to a higher level and aligning around strategic and intermediate outcome-oriented goals helps make the misalignment transparent. Let's say we identified such a misalignment. What can we do? One approach I've seen work is creating a product group that brings together several teams with some potential affinity/overlap - even if they are separate right now. By bringing these products (and the teams working on them) together and having one shared goal and prioritized outcomes, we nudge the team toward being able to work on additional products. But this won't happen on its own. We will need to be explicit about the goal of this structure and the expectation of improved team flexibility. ## We would need to make our intention to build flexibility explicit - [Think of it as a "Flexibility Runway"](/blog/is-your-safe-agile-release-train-flexible-enough)

Pushing The Boundaries of a Product Portfolio

Yuval Yeret — Mon, 10 Feb 2025 00:00:00 GMT

_“We have to have this product capability - it’s a key element of this business initiative we already committed to.”_ The essence of the Product Operating Model is to empower product teams to achieve outcomes without prescribing to them what outputs to deliver. I often encounter organizations who adopt a Product Operating Model as an intervention into how they build products. Frequently, business investment decisions are made outside of the model. When a business initiative has already been green-lighted, asking too many questions about whether to invest in the product capabilities needed to support it can be a career-limiting move for a product professional. The alternative I often see is "rubber stamping" - going through the motions - asking the questions just because your process dictates it, even though everyone knows the outcome. **Unfortunately, Just saying you are "Product-oriented" doesn't automatically make you product oriented. Especially if it's just the product/engineering organization that is product-oriented.** So, what can you do in these situations? To start with - acknowledge and manage this reality. Clarify which initiatives are automatically greenlighted based on business decisions and which are discretionary product portfolio investments oriented around strategic product portfolio goals. Work closely with business stakeholders so they can see the value of outcome-oriented evidence-based management when applied to product initiatives. Respect their decision making authority about business initiatives. . Discuss and define a clear process for managing business-driven and product initiatives. Don't waste time on rubber stamping. Reviewing this ratio can bring transparency and enable a constructive evidence-based conversation. For business-driven initiatives, look for ways to deliver product outcomes incrementally. Enable/encourage incremental/iterative rollout of the business initiative. Build trust through improved execution flow and predictability. Look for opportunities to apply product oriented techniques to the business investment decision. (Find a friendly early adopter business stakeholder who's willing to acknowledge uncertainty) You'll probably get better traction by figuring out what's frustrating business leaders about how business initiatives are managed, then by telling them "we're using a product operating model now and this is how you should work". Don't ask me how I know. ## How have you navigated the tension between pre-approved business initiatives and applying a product-led, evidence-based approach in your organization?

When and How To Organize Your Agile Release Trains (ARTs)

Yuval Yeret — Fri, 07 Feb 2025 00:00:00 GMT

The idea of bringing dependent teams together to collaborate better and minimize cross-dependency overhead isn't unique to SAFe. It's just a fractal of the pattern of an agile cross-functional team, which Agile hasn't invented either, just leveraged. Here's how you might go about designing effective ARTs: - Examine your work - what's on the roadmap, what's the vision, etc. - and how it will hit the different teams/groups in the organization. - Look for ways to group teams that localize as much collaboration/dependencies as possible. It will never be perfect. - These should be your ARTs (or Tribes, or scrum of scrums, or Product groups) - Ideally, each of these should own a major strategic theme for the organization or a major product where they focus on the north star for that product and are empowered to explore, build, and deliver value in that area. There will still be dependencies. Sometimes, even a lot. For most brownfield organizations where SAFe is considered, the architecture will look like iron spaghetti, people will be quite specialized, and to be honest, probably some of the groups you create won't be ideal because of politics, siloes, and turf wars. It's tempting to add more and more processes to manage these dependencies across these ARTs/groups. SAFe even has patterns for doing that (Solution Trains etc. ) which makes it tempting. Avoid that if possible. Use these dependencies to start a conversation about (re)organizing around value. **Descale if you can. Scale if you must.** I've seen examples where a new ART was created to tackle a cross-cutting initiative because it made more sense than managing slices of it across multiple existing ARTs. It goes against the common principle of stable teams, but it's a tradeoff sometimes worth making (no by-the-book prescription, just a set of principles to help guide you...) The other thing to consider is architecture. Can we improve the architecture to break down some dependencies? Amazon avoided the need for ARTs through an edict to provide an API for everything so two-pizza teams can tackle their work with minimal/no dependencies on other teams. Not many organizations are willing to do that. However, as leaders and practitioners, we should continue advocating for these interventions. The bottom line is - creating an ART that brings together dependent teams might be the best you can do right now. The north star is a topology where each agile team is as empowered and decoupled as possible, even within such an ART. And minimum situations where ARTs need to collaborate with others. You might never get there, but keep trying if it makes economic sense. ## PS In the [Portfolio Agility Trail Map](/the-portfolio-agility-trail-map), I share a typical scenario where the portfolio lens is used to see the need for (re)organizing around value. This happens organically, almost inviting itself, rather than a big design upfront (you can imagine the change management benefits of that...) _Improving portfolio flow requires both the right practices and the right mindset. [Explore Portfolio Agility advisory](/work-with-me) or [let's talk](/work-with-me)._

How To Manage a Product Transformation Project

Yuval Yeret — Wed, 05 Feb 2025 00:00:00 GMT

For the fun of it - the next time a big consultancy gives a big presentation to your organization, pitching a POM - ask them how they recommend managing this transformation. And see if what they describe looks more like a Project or a Product. For example - Will they measure [vanity metrics or product metrics](/blog/aarrr-pirate-metrics-for-change-adoption)? It just goes to show how tempting these vanity metrics are. How hard it is to talk about the real WHY (especially when the WHY is because a big consultancy firm sold us on it...) How frightening it is to look at the actual outcomes of our initiatives. Here's the thing - As change agents driving a product operating model, we are asking people to start being accountable for outcomes. To avoid specifying a book of work and share the purpose, be open to a conversation where we look at the efficacy of delivering what they asked for. We should show some leadership by example. Here's our initiative. Here's the outcome we believe it will achieve. Here are the leading indicators we will track along the way. Here are our "kill criteria" for it. If we can use a product operating model to develop our product operating model, we stand a chance of actually getting the organization to use it. Both because it will be fit for purpose and because we will have a great case study to share. ## Check out the [Product-oriented Portfolio Agility Trail Map](/the-portfolio-agility-trail-map) for deeper insights on how to leverage product orientation to improve product orientation.

From Blueprints To Trail Maps

Yuval Yeret — Sun, 02 Feb 2025 00:00:00 GMT

When implementing agile portfolio management, leaders' first—and often most daunting—question is: “Where do we start?” I’ve taught my share of frameworks. In some cases, a comprehensive blueprint or roadmap makes sense. They feel safer to people from traditional project/program management - who ARE often the exact people leading the move towards agile ways of working, especially at the portfolio level. But this sense of safety and predictability is often misplaced. More often than not by the time we're deep into the actual implementation, you've either learned quite a bit and need to revise the blueprint (at which point a lot of the work on details was a waste of time) or the blueprint acts as a set of blinders so you ignore the learning, stick to the plan, and miss the mark on delivering the change outcomes. A blueprint also comes with the baggage of requiring people involved with the change to grasp a lot, plan in depth, and, most importantly, commit to comprehensive change. What often works better is a more straightforward, iterative, evolutionary approach. **Think [Trail Map](/the-portfolio-agility-trail-map) rather than a blueprint.** It highlights the trails but gives you options for approaching them. **What does that look like when pursuing Portfolio-level agility?** - **Visualize Your Portfolio Flow:** Start by laying out all your initiatives on a transparent board. This isn’t about micromanaging every task—it’s about seeing the big picture. - **Manage and Shape Flow:** Once you have visibility, look for opportunities to reduce overcommitment. Fewer, better‑funded initiatives lead to a more empowered, outcome‑focused team. - **Organize in ways that accelerate Flow:** Experiment with ways to organize in a more streamlined fashion. Try these approaches on specific examples, see what works, inspect, and adapt. - **Use Evidence-Based Management To Improve Outcomes:** Orient your most significant initiatives towards outcome-oriented goals and steer based on feedback loops. - **Evolve:** Use evidence‑based management to see what works and let that learning inform future decisions. By thinking of your portfolio as a living, evolving entity—and using a trail map to guide your early steps—you can gradually build a product‑oriented, agile portfolio without overwhelming your teams or leadership. As a side benefit, leadership will see, learn, and model the behaviors and culture needed for organizational agility… How are you thinking about bringing agility to your company/portfolio? What’s one first trail you can explore? ## PS The [Portfolio Agility Trail Map](/the-portfolio-agility-trail-map) is an email course where I share what I’ve learned about using this approach. Similarly, the [Mastering Organizational Traction Trail Map](https://pages.yeretagility.com/mastering-org-traction) applies this concept to improve organizational traction for growing companies.

Cross-Product Initiative Ownership

Yuval Yeret — Sat, 01 Feb 2025 00:00:00 GMT

Many organizations tackling cross-product initiatives struggle with initiative ownership. At its heart, a cross-product initiative involves significant impact across multiple products/groups (sometimes called a portfolio) As organizations scale up, they get to the point where they need to tackle cross-product/cross-organization initiatives. These are often significant, complex endeavors aimed at solving an expensive problem or opening a very lucrative door for the organization. In other words - they're strategic bets. Even organizations with a strong product culture are tempted to leverage classic program management to deal with these initiatives. What does that look like: - Tracking to committed scope (rather than steering towards outcomes), - Control (rather than aligned autonomy). - Dissonance between the way initiatives are managed and how product teams are working. - Change Control (rather than collaboration and flexibility) Sadly, this style of management isn't appropriate here. In a product-oriented operating system, we realize that these are complex and treat them in many ways like products - including assigning product ownership accountability to them - e.g. in the form of Initiative Ownership. **But the point isn’t to call someone an Initiative/Epic Owner. The value comes from them acting like one.** **Product-oriented Initiative Owners:** - Act as a visionary for their strategic initiative. - Own the Outcomes - Connect to customers,\\ - Collaborate with a multitude of teams on finding creative and effective ways to test and deliver outcomes. - Make critical decisions as well as decentralize when possible while providing clarity and context. - Focus on the risks/uncertainties and create discovery and delivery plans that provide plenty of opportunity to inspect, adapt, or stop. - Leverage influence to drive collaboration towards outcomes across multiple products and departments. You might say they act like Professional Product Owners... ## Are you looking at tips and tricks for bringing product orientation to the portfolio level? In the [Portfolio Agility Trail Map, I share what I’ve found helpful when helping organizations like yours on this journey](/the-portfolio-agility-trail-map).

Organizational Traction w/ an OKRs Kanban

Yuval Yeret — Mon, 27 Jan 2025 00:00:00 GMT

What gets measured gets managed. But setting OKRs isn't enough. The flow and traction of OKRs need to be managed as well - otherwise, you'll find yourself in the OKR swamp. Using an OKR Kanban can help you both see the swamp and improve the flow and traction of OKRs. Here's an example - ![](/assets/images/blog/OKRs-Kanban_2025-01-24_19-02-10-1024x557.png) Here are some of my favorite patterns for managing OKR flow using Kanban: - Use **One** OKR Kanban board. It's okay and preferable to see OKRs from multiple departments/teams/groups on the same board. It reinforces the transparency and alignment as well as interesting conversations about misalignment. - Use an OKR workflow for considering/exploring possible objectives/bets, planning/committing, actual experimentation/execution towards outcomes, and reflection/adaptation. This will help reinforce a product-oriented mindset - for both product and business OKRs! - Consider a workflow that helps you identify struggling OKRs to focus on - e.g., a Red/Yellow/Green - and make sure to start Red and expect OKRs to "Earn" their movement to Yellow/Green based on actual evidence. (This is a poor man's Work Item Aging approach) - Limit the number of OKRs in progress and consideration - Focus drives traction. - Visualize who's involved in which OKR, as well as the level of coupling/integration. - Decide whether to visualize KRs independently - this can provide interesting insights but can also hurt transparency if there's too much information. - If your board is too busy - that says something! - Use your OKRs Kanban when checking your OKRs and considering any new OKRs or other significant work. It can help facilitate healthy conversations. How are YOU managing your OKRs? Do you have any favorite patterns for seeing and improving OKR flow? **Looking for ways to improve flow and traction on your company's strategic initiatives?** ## The [Organizational Traction Trail Map](https://preview.convertkit-mail2.com/click/dpheh0hzhm/aHR0cHM6Ly9wYWdlcy55ZXJldGFnaWxpdHkuY29tL21hc3RlcmluZy1vcmctdHJhY3Rpb24=) is a practical, no-fluff email course designed to help leaders of scale-up and midsized organizations break free from scattered priorities and bring organizational flow, focus, and clarity.

What's The Right Timing For Portfolio Agility?

Yuval Yeret — Mon, 13 Jan 2025 00:00:00 GMT

Most organizations wait way too long to adopt some portfolio-level agility practices. They've been told, "You can't scale what's broken," so they wait until they nail agile at the team and product group level. What if fixing what's broken REQUIRES focusing on the upstream that's shaping the work and context of these teams? Back in 2012 or so, I met an SVP responsible for a 1000-person delivery organization that was working in a traditional waterfall. Critical Chain optimized waterfall. But still. Component Teams. Heavy coordination and integration costs across multiple products. Build that takes 2 weeks to integrate. Riki and her team ran a very successful and profitable shop. However, they recognized that in order to satisfy their customers, they often had to accept change out of cycle, which created a constant fire drill. We discussed options. What Riki liked was starting with visualizing, understanding, and managing flow at the portfolio level, to break the waterfall. We got it going within weeks. (Did I mention Riki and the team were experienced, highly motivated operations-focused leaders? ). It didn't take long for Flow times to start improving and for "Welcome Change" to be a more reasonable proposition. Over time, we've noticed how much "cross-product" work this portfolio delivered and started exploring ways to reorganize around value. We started introducing more and more agility principles and practices (eventually, they did reorganize to stream-aligned cross-product groups focused on the REAL product and leveraged team-level agile ways of working). Here's the thing - Starting at the Portfolio level gives you as a leader, tons of leverage to make an impact on the product-oriented agility of your organization - by tackling the systemic constraints to Product thinking, Flow, and Empiricism and allowing you to learn and model the behaviors you expect from your people. ## **Interested in bringing product agility to a multi-product/portfolio context?** [**Check out the Portfolio Agility Trail Map**](/the-portfolio-agility-trail-map)**—a free email course based on the lightweight Kanban-first approach described above, combined with modern concepts such as the Product Operating Model and Evidence-based Management.**

Navigating The GenAI Storm

Yuval Yeret — Wed, 08 Jan 2025 00:00:00 GMT

How can we leverage GenAI to help us build better products? Operate more efficiently? Close more deals? Reduce customer churn? A Company's GenAI transformation is a classic example of volatility, uncertainty, complexity and ambiguity - and the need to try things out, inspect, and adapt, by multi-disciplinary teams. In other words, it's the classic use case for an agile, product-oriented approach. Not for building a Product. But for building/evolving your Company. Instead of spraying and praying GenAI all over the place... Identify the jobs to be done, functions, and key processes that are constraining the company. Apply some good old process improvement (don't worry about GenAI yet) Once you stabilize a process that makes sense - THEN consider how GenAI can help minimize the effort. Example? Might seem meta - but can GenAI help make agile/Scrum more efficient? Start by looking at your agile ways of working and eliminating some waste (e.g. spend less time tasking and estimating and more time delivering... ). Don't worry about how GenAI can improve estimates. Start by making sure you need sprint-level estimates to begin with. Let's say you decide to move to smaller behavior/example-driven stories. After you try that for a bit, you can see if GenAI can help slice into these smaller bits. Can GenAI help craft / grade OKRs? Sure, but I'd suggest first making sure to fix your OKRs before you start relying on GenAI. Otherwise you might save some time on creating them, but stay stuck with the same antipatterns. Yours, Yuval "Let's Leverage Agile for Your GenAI Transformation" Yeret

Product-Oriented Portfolio Leader

Yuval Yeret — Tue, 07 Jan 2025 00:00:00 GMT

What does Product Oriented Portfolio Leadership Look like? These leaders ... - Model agile leadership by fostering collaboration, decentralized decision-making, and **servant leadership** to inspire trust and empower teams. - **Align** portfolio objectives, vision, and strategies with organizational goals, ensuring they are **outcome-oriented,** measurable and continuously updated to reflect strategic needs. - **Organize** value streams and teams around products and strategic themes in a way which **empowers** them to run fast with minimal dependencies and maximum local decision making leading to **fast learning** and improving the likelihood of great product outcomes. - Optimize portfolio processes to ensure **smooth flow**, align governance with lean principles, and **promote a sustainable pace** for long-term health and efficiency. - Proactively mitigate risks through **empiricism, experimentation, and evidence-based decision making.** - **Model Focus, Flow, Outcome-orientation and Empiricism i**n how the organization's most significant initiatives are considered and managed. Does this look familiar? Honestly, You could come up with this list yourself. All I did was think through what it would look like to apply the [Agility Principles](/principle-based-agility-assessment) for Portfolio Leaders. But I think its a nice example of the power of starting with principles rather than mechanics/practices. Does it make sense for Portfolio Leaders to use Portfolio Kanbans? Epics? OKRs? Guardrails/Boundaries? Team Topologies? Very often it does. But these are all much more powerful when you start with the intent and then choose what works in the context. So, instead of a checklist of practices you're using (or not) - how about reflecting on whether leadership behaviors are aligned with agility principles? ## (FWIW That's the model I'm using when coaching/mentoring leaders - whether they consider themselves portfolio leaders or not...)

Next Steps Towards Product Portfolio Agility

Yuval Yeret — Thu, 02 Jan 2025 00:00:00 GMT

You're [actively managing the flow](/blog/actively-managing-portfolio-flow) of your most significant investments. You've started conversations about how to [descale by organizing around products](/blog/descale-your-portfolio-by-organizing-around-products). What's next? It depends. Where do you want to improve? Outcome orientation? Aligned Autonomy? Sustainable Pace? Predictability? Empiricism? The principles of agility apply at the portfolio level as well. A [principle-based assessment](/principle-based-agility-assessment) can help you see where you are and support a structured conversation about where to go next. Just make sure to discuss WHY you believe improving in a certain area makes sense. What would be the impact, how does that support your strategic transformational goals. This is also where the journey becomes less structured. A Choose your own adventure. Here are some example paths - When portfolio leaders wanted to improve empiricism and reduce investment risk we improved the definition of workflow to better reflect and encourage product discovery behaviors and introduced a key decision whether to go through discovery or skip it straight to delivery. When a product leader wanted to empower product teams, even when working on the most significant initiatives, we emphasized structuring these initiatives around outcomes, using OKR language instead of classic PRDs and business cases. When an enterprise was struggling with unsustainable pace, a key intervention was a portfolio planning exercise inspired by agile planning techniques, where the different involved product groups got together and collaborated on creating a [realistic portfolio roadmap using pull mode](/bringing-the-magic-of-pi-planning-to-the-portfolio-level-safe-summit-talk-follow-up). In a large enterprise with multiple portfolios, we tackled some common patterns across the enterprise, and other challenges that were more specific to one portfolio. For example, a Technology Services portfolio focused on applying product thinking to enabling work and identifying/nurturing internal platforms - intending to minimize dependencies and synchronization needed between them and the business-facing portfolios. ## **What portfolio-level challenge are YOU working on? (Which of these intervention paths would you like me to explore in more depth?)**

Descale Your Portfolio By Organizing Around Products

Yuval Yeret — Fri, 20 Dec 2024 00:00:00 GMT

Is your [Portfolio Kanban Board Busy](/blog/what-do-busy-portfolio-kanban-boards-tell-us)? Do you feel like almost any outcome of any significance needs to be managed at the Portfolio level because it involves several of your product/development groups? One solution would be to invest in better portfolio management, coordination mechanisms, etc. A better solution would be to descale. To find ways to organize around outcomes. The goal is to minimize the number of outcomes spanning product/development groups. That's the whole idea of Empowered Product Teams. Also known as Stream-aligned in Team Topologies. Empowered means having the decision rights, resources, and skills needed to discover and deliver product outcomes with minimal dependencies. Decision rights are meaningless without the resources and skills. You can empower Product Managers - but if the Product Team is heavily dependent on other teams, than you're only empowering them to negotiate and spend time in coordination nightmare, that often does flow up to the cross-product layer (also known as Portfolio...) for resolution. When portfolio leadership teams approach me with this challenge, I guide them through: 1. Identifying the constraints - the usual suspects involved in everything. In many cases, 80% of the dependencies map to 20% of the teams... 2. Looking for product topology options that might work better. 3. Considering whether architectural interventions such as introducing a self-service platform can help melt some of the iron spaghetti. 4. Considering aggressive cross-product T-shaping - enabling people/teams to do work currently limited to specific, constrained teams. We then compare the different design options (as well as the current state) based on: - How much of the portfolio's work will be localized using this option? Aim for the majority of the work to be localized. If possible, 80% would be even better. - How much of a change from the current state is this option? Change is hard...? - How much product/technology/people risks does this option entail (e.g., distributing a core capability with limited know-how)? - How future-proof is this option? How aligned is it with our strategy? What's on the horizon? When we find a significantly better alternative worth exploring, we evolve it like a product - we clarify the desired outcomes and leading indicators, agree on a discovery approach, and tackle it incrementally if possible. And yes, this is a [fractal](/blog/i-see-snowflakes-and-fractals-i-see-them-all-the-time) of how you could tackle a product group that is facing too many dependencies, which is a fractal of how you improve the resiliency and flow on an empowered product team. Or, in other words - [“Turtles all the way down”](https://en.wikipedia.org/wiki/Turtles_all_the_way_down)

What Do Busy Portfolio Kanban Boards Tell Us?

Yuval Yeret — Wed, 18 Dec 2024 00:00:00 GMT

They tell us a story of slow, centralized decision-making, often related to classic program management culture combined with an iron spaghetti portfolio where delivering product outcomes often requires wide collaboration across teams and even teams of teams. An agile, product-oriented portfolio relies mainly on providing strategic guidance and alignment, not managing every Portfolio Kanban board investment. This is why, once you establish a Portfolio Kanban board to see the investments you're managing, you should think about whether you actually NEED to manage these investments at the portfolio level. It might be time to inspect and adapt the definition of portfolio workflow - focusing on which items should flow at the Portfolio level. A few elements we often consider are - 1. investment size 2. Strategic opportunity/risk 3. Level of cross-product collaboration needed Essentially, we want the portfolio conversations to focus on the larger, higher opportunity/risk high cross-product collaboration investments, and decentralize decision making to empowered product teams for other investments. It doesn’t mean portfolio leaders don’t care about these other investments. But they trust their product teams and maintain a lighter touch interface, compared to those investments they want to focus on. Here’s what you can do - Analyze the cards on your portfolio kanban according to these 3 criteria. Let’s say a grade of 1-3 for each. This means the overall grade for each investment/card will be between 3-9: - 3-4 This should probably NOT be a portfolio level card. - 5-6 Let’s have a conversation about whether we want to track these - 7-9 This SHOULD be a portfolio level card. (feel free to add a criteria and use whatever formula works for you - I provide this here just for illustration purposes) What if it turns out most of your cards SHOULD be portfolio-level cards? One option is that you’re running a good portfolio approach already with empowered stream-aligned product teams working on smaller, more focused investments most of the time. But if you have lots of cards AND it looks like they should stay at the portfolio level - now its time to think about **how to descale your portfolio by organizing around products, and building products using continuous discovery.** (in other words, it is time to continue your product portfolio agility journey...) ## **What does your Portfolio Kanban Board tell you?**

Improving Portfolio Flow Using Flow Metrics

Yuval Yeret — Tue, 17 Dec 2024 00:00:00 GMT

So you have a Portfolio Kanban board managing your biggest investments. You’re actively managing the flow by using this kanban board in your conversations about the portfolio. Kanban/Flow Metrics can help sharpen your flow focus even further. The [four flow metrics](https://kanbanguides.org/english/#elementor-toc__heading-anchor-10) described in the Kanban Guide for Scrum Teams / Kanban Guide are Work in Process (WIP), Cycle Time, Throughput, Work Item Age (WIA). How can these metrics help us at the Portfolio level? Yes, We can see the current **WIP** just by looking at the Portfolio Kanban. We can drive additional insights by explicitly measuring the WIP level, seeing its trend over time, and measuring it both by counting items in each stage of the workflow as well as looking at the overall investment size that is in process. Hopefully, the insight is - we really have too many things in the process, and we should do something about it. And over time, measuring WIP will show whether what we’re doing is successful. **Cycle Time** for portfolio-level investments will be measured in months. (Not weeks, and hopefully not years…). It will also have higher variability since we’re not forcing our portfolio investments to fit a timebox. Cycle Time gives us key information about our time to learn and time to market. Over time, we can hopefully establish a Service Level Expectation (SLE) that will help us manage our expectations around investment workflow. **Throughput** doesn’t care about the size of the investments. It counts investments “finished” in a unit of time. Remember - in most portfolio workflows finished means “we’re done treating this as a high profile investment - its now back to business as usual”. With information about the overall throughput, we can have some interesting conversations about the funnel leading into the workflow. For example - if we learn that our throughput is 3 investments a quarter (I know multiple portfolio teams who would love to have that) - how many investments does it make sense to consider each quarter? What’s the proper shape of the consideration funnel? Where are our bottlenecks/constraints? The **Work Item Age** metric helps us anticipate/intercept investments that aren’t meeting our expectations by showing us how much time a work item has already been active. Even in the case of portfolio investments with a long time horizon, Work Item Age can help identify anomalies. **Now what? Start measuring flow metrics for your Portfolio Kanban** ( as soon as possible because it will take time to see meaningful data ) If you have some historical data, you can try reverse engineering flow metrics to accelerate establishing a baseline. This sort of data can be helpful in convincing portfolio leaders and stakeholders that the portfolio is more like a swamp than a river… Finally, a warning. It’s essential to focus on flow. And it is the right place to start. But it's far from enough. **Make sure that you’re leveraging flow to improve outcomes**. ## This is where we’ll turn next in this Product Portfolio Agility series of emails. (I'm sprinkling on this topic amongst other topics. If you want me to double down on this topic - reply and let me know!) _Improving portfolio flow requires both the right practices and the right mindset. [Explore Portfolio Agility advisory](/work-with-me) or [let's talk](/work-with-me)._

The Story Points Detox Plan Shortcut

Yuval Yeret — Fri, 13 Dec 2024 00:00:00 GMT

_Reader Mary shared an inspiring story of introducing modern flow metrics in parallel to classic agile metrics, such as Velocity, to improve flow on her team._ _If you haven't guessed so far, introducing Flow is one of my favorite patterns for moving from mindless mechanical agile (Agile Theater) towards intent-driven principle-aware agility. There's something about working on Flow that is magical in how it wakes you up to the principles whether it's at the personal, team, or portfolio level._ _Introducing flow metrics is a great way to do that. Visualizing the work using a Kanban board is another. But as Mary highlights, people can get hung up on their beloved Velocity..._ _Today's post is an example of horrible flow. It was stuck deep in my drafts for 5 years. Not sure how that happened. But anyhow, here's the story of the Story Points Detox Plan - a blast from 2019 (don't you wish some days we were all back in 2019? )_ ## The Story Points Detox Plan So you've read about the #NoEstimates movement, and you're thinking about trying flow metrics instead of velocity. What next? How do you convince your team and stakeholders to part away with their beloved velocity? Well, Agile is all about Empiricism, right? So, your first step should be to run an experiment. Actually, No! You probably already ran the first experiment. You can consider previous Sprints your team planned and delivered using Story Points and Velocity as your dataset. You probably have a chart along these lines that shows you your historical Velocity and helps the Scrum Team when planning the Sprint or Release. Using the same data, create a similar chart where the difference is in the Y-axis. Instead of showing the sum of Story Points-based Velocity for each Sprint, show a count of PBIs Done in each Sprint. Compare the shapes of those two charts. Is one of them more stable than the other? Do you feel more comfortable creating a forecast using one of them? Many teams find that the count-based chart is much more stable, and they feel more comfortable forecasting the number of items they'll deliver in their next Sprint than the number of Story Points. Maybe that's the case with your team, maybe not. Looking at these two charts and having this discussion can be a great Retrospective activity with the Scrum Team if you want the team to consider experimenting with a new approach to planning. **Are you using [Flow Metrics](/blog/4-key-flow-metrics-and-how-to-use-them-in-scrums-events) in your team/organization? If so - what pattern did you use to introduce it? If not - which pattern will you use?** ## **Where else can you apply this pattern? Where else do you already have some data/evidence that you can use to build confidence to try something different?**

Observations From The Agile Frontier

Yuval Yeret — Thu, 12 Dec 2024 00:00:00 GMT

As we wrap up 2024, I thought I'd drop by and share what I see in the agile/agility world and my thoughts about the future. Is Agile Dead? No, but mechanical Agile Theater is undoubtedly out of favor. While organizations still need to be more agile, more leaders understand that agility requires focusing on intent and principles. Organizations are significantly reducing investments in training and certification and turning their attention to making it work (what I call - [Fixing/Repairing your Agility](/fixing-your-agility 'Fixing Your Agility')) Product Operating Models are all the rage, but under the covers, the answer to HOW to become product-oriented goes through the same agility principles. (And there’s significant concern that [the Product Operating Model will become the new theater](/transformed-yet-still-the-same-an-all-to-familiar-agile-story '“Transformed”. Yet still the same. An All Too Familiar Agile Story')) While this is happening in the Enterprise Technology space, Agile continues to make headway beyond software and product development. Some of you are at the forefront of leveraging agile ideas in a variety of product, commercial and organizational initiatives in [BioTech](/iterating-beyond-software 'Iterating Beyond Software – Applying Agile/Evidence-Based Management in Consumer Goods, Food & Beverage, Pharma/BioTech and Beyond'), [Consumer Goods](/gillette-2 'Gillette – Designing and Productizing a New Razor with Scrum'), Pharma, Deep Tech and beyond. We’re also seeing a convergence of agile/agility and strategy. It is becoming clear that business operating systems need to adopt agility principles. Operational leaders are working on deploying frameworks such as [OKRs](/blog/okrs-sk-but-we-dont-know-anything-better-scaling-founder-mode-by-fixing-okrs) and [EOS](/blog/entrepreneurial-operating-system-traction-how-does-it-relate-to-agile-scrum) to improve strategic alignment AND enable effective execution. I’ve also been reflecting on where I fit into all of this. **I help leaders who want agility but are skeptical of by-the-book frameworks streamline processes, improve flow, and accelerate innovation outcomes at scale.** **Unlike many others in this space, I focus on pragmatic, intent-based, context-adaptive, evolutionary application (instead of prescriptive by the book dogmatic installation of frameworks)** More concretely, this means helping leaders fix agility and bring it to new frontiers. It means continuing to work with technology/engineering/transformation leaders, doing more work with product leaders, and helping early adopter operational / company leaders who are pioneering strategic / change agility. And, of course, continuing to reflect and share my point of view and applicable insights with you, my readers. I hope these themes are on your mind as well. Every reply/comment I receive from you helps further my thinking (and makes my day!) ## **Speaking of that - I’m working to get my point of view on agility in front of more leaders. With the above framing in mind - Can you think of 1-2 people who will enjoy these emails? Would you mind forwarding the ones you like to them?**

De-Risk Product Development w/ Leading Indicators

Yuval Yeret — Wed, 11 Dec 2024 00:00:00 GMT

Here's one major reason why your OKRs are enabling waterfall projects and not product orientation. And its related to the common advice to focus on Outcome OKRs ... We constantly talk about moving from outputs to outcome OKRs. Providing alignment to the real goal and enabling flexibility and discovery. What we should talk about more often is that to steer towards outcomes in an environment of uncertainty, we need continuous feedback. We need leading indicators. Easy to say, harder to practice. Especially when you're working on larger investments (think portfolio-level bets or new products) Coming up with leading indicators requires us to build a hypothesis around what will enable/drive the desired customer behaviors and outcomes. That requires deep insight. This raises a question I've been pondering recently: When does it make sense to develop leading indicators? Key Results? On one hand, developing leading indicators requires intimacy with the problem space. On the other hand, it would be good to know whether we have a way to steer using feedback before going into a major investment. Where I'm landing for now is: \- consider and prioritize potential investments based on desired outcomes (lagging indicators). \- For investments that require discovery (aka bets) determine leading indicators and a clear approach for steering/discovery based on feedback \- Consider the leading indicators and discovery approach when prioritizing/approving these bets. \- Break the bigger investment into smaller slices that each aim to move the needle on the leading indicator. (this is hard but is where the magic is!) \- Use the leading indicators to steer during discovery/delivery. Be open to pivoting both the investment as well as the leading indicators we use to manage it, based on new information. ## What's your take? Are you insisting on establishing leading indicators? What challenges are you facing using them to guide continuous product discovery/development?

Actively Managing Portfolio Flow

Yuval Yeret — Tue, 10 Dec 2024 00:00:00 GMT

Seeing the swamp is the first step in shaping it into a river. You've established a Portfolio Kanban — a flow-based view of the significant work taking place in your organization (also known as your portfolio). More likely than not, there are a lot of cards on that board, like a traffic jam in rush hour. ## What Is Active Portfolio Flow Management? Active portfolio flow management is the practice of regularly reviewing your Portfolio Kanban not just to see what's in progress, but to make deliberate decisions about what to start, stop, accelerate, and deprioritize — based on flow signals rather than political pressure. The distinction from passive portfolio management is important: a Portfolio Kanban that leadership looks at once a month without making decisions is just a status dashboard. Active management means using the board as a decision-making tool in a regular cadence. ## How Do You Review a Portfolio Kanban Effectively? The most powerful shift is reviewing the board **right to left** — starting from the work closest to done — instead of left to right, which is the natural direction people tend to talk about work. By using this "Hebrew mode," you are focusing on finishing work already in progress. You only get to discuss starting new work after the weight of all the investments already in progress has essentially demotivated you from even considering it. This is a nifty system for nurturing a habit of _stop starting, start finishing_. In practice, a right-to-left review asks: - What is closest to done and needs a final push? - What is stalled and needs a decision — continue, pause, or cancel? - What dependencies or blockers are preventing flow? - Only then: is there capacity to pull new work? ## What WIP Limit Patterns Work for Portfolio Kanban? When you need to reduce a backed-up portfolio, several patterns apply: **No New Work** — a moratorium on starting new investments until existing ones finish. Painful in the short term; powerful for building the stop-starting muscle. **Freeze** — a harder stop where no new cards can even be created until the portfolio thins. Used when the backlog itself is out of control. **Differentiated Service** — applying explicit classes of service so mission-critical investments get flow priority while lower-priority work waits. This prevents the WIP limit from starving the most strategically important work. **Soft WIP Limits** — setting a maximum number of active investments per lane and using that as a forcing function for conversations rather than a hard rule. These patterns are not mutually exclusive. Organizations often combine a soft WIP limit with a differentiated service layer for strategic items. ## What Constraints Does Portfolio Flow Management Reveal? As you start focusing on flow, you'll begin to see constraints you couldn't see before: **Bottleneck teams or groups** — the one team involved in everything. When you see them on 80% of portfolio cards, it's a signal to be much more selective about what you pull into their lane — and a signal to invest in either growing their capacity or reducing dependencies on them. **Investments that are too large** — work items so big they occupy their lane far longer than others. Large investments create the illusion of progress while consuming capacity for months without delivering value. Breaking them into independent, separately valuable investments accelerates time to market. **Blind investments** — work with no leading indicators of whether it's going well. When a card has been in flight for six months with no outcome signal, you are flying blind. This is an excellent opening for introducing outcome-oriented, evidence-informed portfolio management — OKRs, intermediate milestones, or explicit hypothesis tracking. **Dependency gridlock** — investments that can't move because they depend on each other or on shared infrastructure. Visibility at the portfolio level surfaces these dependency clusters far earlier than project status reports do. ## What Is the Relationship Between Portfolio Flow and Product Portfolio Agility? Actively managing flow on a Portfolio Kanban won't magically turn a project-oriented organization into a product-oriented portfolio. But it is one of the most effective ways to **start the journey**. The reason: Portfolio Kanban creates a shared visual truth that forces conversations about investment strategy. Those conversations — "why are we starting this if we can't finish that?" — are the seeds of lean portfolio thinking. The maturity path typically looks like: 1. **Visible portfolio** — everything is on a board; leadership can see it 2. **Actively managed flow** — regular right-to-left review; WIP limits applied 3. **Outcome-oriented portfolio** — each investment has explicit hypotheses and leading indicators 4. **Product-oriented portfolio** — organized around persistent value streams rather than temporary projects Most organizations get stuck between steps 1 and 2 because they never make the review cadence real and action-oriented. ## What Metrics Matter for Portfolio Flow? The same four flow metrics that matter at the team level apply at the portfolio level: - **Throughput** — how many investments are we completing per quarter? Is it going up or down? - **Cycle time** — how long does it take from approval to delivered value? What is our 85th percentile? - **WIP** — how many investments are simultaneously active? Is that number going up or stabilizing? - **Work item age** — how long have each of our in-progress investments been running without completing? Work item age is particularly powerful at the portfolio level. Any investment that has been in-progress for longer than 2x your average cycle time is a candidate for an active conversation: accelerate, descope, or stop. ### Practical Implementation Tips - **Kanban vs. Spreadsheets:** A spreadsheet tracks what is planned; a Portfolio Kanban tracks what is actually flowing. Use Kanban to surface the flow problems—bottlenecks, blocked work, and excessive WIP—that traditional project status reports often hide. - **Establish a Review Cadence:** Aim for a weekly, 30-60 minute action-oriented portfolio review at the leadership level. Supplement this with a monthly strategic session to connect flow data back to business outcomes and investment strategy. - **Avoid the "Status Tool" Trap:** The biggest mistake is using a Portfolio Kanban only for reporting. It only delivers value when it changes decisions—specifically what you start, stop, or accelerate. If a review ends without a decision, the system isn't working yet. - **Break Down Multi-Quarter Work:** Large, long-term investments should be decomposed into independently valuable milestones. Managing these as distinct portfolio items reduces the risk of late-stage discovery and waste. --- _Interested in building a lean portfolio management system in your organization? [Explore Portfolio Agility advisory](/work-with-me/portfolio-agility) or [get in touch](/contact)._

‘Let’s open the (Portfolio Kanban) Cards’

Yuval Yeret — Mon, 09 Dec 2024 00:00:00 GMT

A question you're probably asking yourself as you're trying to [visualize and manage the](/blog/visualizing-portfolio-flow-or-lack-thereof) flow of your most significant [initiatives/projects](/blog/visualizing-portfolio-flow-or-lack-thereof) (Aka Portfolio Flow) is - what should the cards represent? What information should they contain? Following SAFe Lean Portfolio Management? your cards will reflect [Epics](https://scaledagileframework.com/epic/). And you’ll probably use Epic hypothesis statements and Lean Business Cases as the artifacts supporting these cards. Focused on Outcomes? Your cards might represent [OKRs](/blog/improving-focus-and-alignment-by-organizing-around-okrs-and-managing-okr-flow) - meaning each card will include an Objective and a small set of Key Results. Serious Lean shop? Your cards might represent [A3](https://blog.crisp.se/2009/09/23/henrikkniberg/1253687880000) documents focused on a problem/opportunity. Inspired by the Spotify Model? Your cards will represent Bets based on [DIBBs](https://blog.crisp.se/2016/06/08/henrikkniberg/spotify-rhythm?ref=https%3A%2F%2Fproduct-frameworks.com) (Data, Insights, Beliefs, Bets) Here’s the thing though if you’re not following any of these approaches, you can start with the cards simply reflecting the artifacts you ARE using to manage your initiatives. Whatever those look like. Start with what you have. Using the different approaches above can definitely help improve the outcome orientation and evidence-informed rigor of your portfolio and nudge it towards being product-oriented. But start with baby steps. Start with visualizing flow. Then, [begin to manage it](/blog/actively-managing-portfolio-flow). Yes, it's even ok to start with [solution-oriented names](/blog/its-all-in-the-name) :-) **Hey - are you using a portfolio kanban? What’s in your cards?** If you want support implementing this in your context, see [Portfolio Agility](/work-with-me/portfolio-agility/).

The Change Agent Catch 22

Yuval Yeret — Fri, 06 Dec 2024 00:00:00 GMT

"_Don't tell me to implement this new process._" "_I don't have time to discuss process._" Many change agents I work with struggle with engaging senior leaders who don't have time for dialogues around systems and ways of working. They also don't appreciate being prescribed a new process. They rarely have time to learn about principles. **What do you do about this catch 22?** One approach which I found helps is to focus on expensive problems. The problems at the top of their worry list. Those problems rarely manifest as system problems. ## Which is why its so hard to "sell" what we do, right?

Visualizing Portfolio Flow (Or Lack Thereof)

Yuval Yeret — Thu, 05 Dec 2024 00:00:00 GMT

You can’t improve what you can’t see. Improving flow at the portfolio level requires seeing it first. How do you see? A Portfolio-level Kanban is a common way to start seeing. Let’s explore what that looks like Let’s discuss how work flows at this level (Definition of Workflow as described in the Kanban Guide) The first thing to agree on is what is the value that flows at the portfolio level. Typically, those will be the organization's significant initiatives to consider and manage. Should it be all initiatives? Just the top 10? Start with all the initiatives the people managing this portfolio/organization/business currently manage. This might be a very long list. Or a very short one. That’s ok. Start with what you have. Don’t stress too much about it (for now). You’ll have plenty of time to discuss what " significant " means later. Now, define the start and finish boundaries. It might look obvious, but there are some interesting questions to explore here. When do you start managing initiatives? When does the idea first float? When the “business” is ready to ask technology to support it? I often see the latter. While I think the former has a better chance of shaping innovation around business outcomes and empiricism, It might make sense to start with what you have and be ready to evolve towards a wider breadth later on as you get buy-in for it. It often depends on who’s on the portfolio leadership team. If it’s the team running the business unit/company, there’s a better chance of getting there. When do we stop managing initiatives? Remember, we’re not managing everything. So when is the right time to move to “business as usual”? Again, start with where you are right now and discuss whether to make a change now or consider it later. Next, you’ll have to define the states that the items flow through in between. You might already have a workflow. Or maybe you will want to take inspiration from SAFe’s LPM, Spotify (Think it Build it Ship it Tweak it) or some other variant. Here's my go-to skeleton... Again, be careful to have a dialogue about whether to start with what you have or leap into a new model. In any case, the key point about all elements of the definition of workflow is that you, as the portfolio team, should own it. What you have right now is just the starting point. Commit to trying it, inspecting, and adapting as needed based on whether it's a good fit for your needs. Over time, you’ll want to bring in better flow, outcome orientation, empowerment/autonomy, and empiricism. You'll be able to see if you're product-oriented and have some evidence that will feed your product topology inspection and adaptation. You have to start somewhere. It's better to start seeing the flow now, then spend weeks/months figuring out your ways of working (not to say product structure), and only then get going. **Let’s call it a day. Tomorrow, you can create your Portfolio Kanban. WDYS?** --- _Improving how your SAFe implementation actually delivers speed and outcomes — rather than process overhead — is a core part of how I work with scaled organizations. [Explore SAFe advisory](/work-with-me/scale-agility-leveraging-the-scaled-agile-framework) or [let's talk](/work-with-me)._

Expensive Problems >> Principles >> Practices

Yuval Yeret — Wed, 04 Dec 2024 00:00:00 GMT

End-to-end flow of value Continuous Improvement Autonomy and Empowerment Organizing Around Value Sustainable Pace Alignment around Outcome-oriented Goals Energized People Leaders who Serve Speed and Empiricism All worthy **Agility Principles** (at least I think so…) But why should anyone care? I mean, it’s **much healthier to focus on principles** than practices as a goal. But even these principles are a form of HOW. They don’t answer the WHY. Ask “So what happens if we DON’T follow this principle?” a couple of times and you will get **closer to** **expensive problems:** - Miscommunication, duplicated efforts, and decreased effectiveness. - Delays and an inability to adapt to changing conditions. - Bottlenecks, demotivated employees, and ineffective product development processes. - High turnover rates and decreased output quality. - Poor team morale, lack of direction, and reduced organizational success. Ask “so what” again and you get to some juicy **expensive problems** business leaders might actually be losing sleep over: - Wasted resources, increased operational costs, and missed strategic opportunities (a really expensive problem in the age where money isn’t free anymore) - Falling behind competitors, losing market share, and failing to meet customer expectations. - Hindered innovation, slowed time to market, and subpar product quality, impacting revenue growth. - Increased recruitment and training costs, disrupted team cohesion, and negatively affected customer satisfaction. - Decreased productivity, inability to achieve business objectives, and a decline in overall organizational health and profitability. Now what? Option 1: You already know you want to focus on a specific principle. Great. Make sure you include a “Why Now” that connects it to an expensive problem. (and if you can’t find one - maybe rethink the conviction on that principle? ) Option 2: Start with a Why conversation exploring the expensive problems your organization is currently having. THEN try to find the agility principle that would help address that problem. Here’s an example: Don’t tell a senior business director “We’re gonna use KPIs now”. Don’t even tell them “We’re gonna work on improving Alignment, Outcome-orientation and Empiricism now” Don’t even tell them “We’re going to use KPIs to improve alignment so that we deliver better business wins” (don't ask me how I know...) **Instead - Facilitate a dialogue around the top expensive problem on their mind. Use Five Whys or Cause and Effect Loops to identify principles that could help. Explore which practices make sense to everyone to try and work on that expensive problem.** Which option would you go for? 1? 2?

Is it Time for Our Agility Work To Go Underground?

Yuval Yeret — Wed, 27 Nov 2024 00:00:00 GMT

It seems like we are working on a lot of initiatives. Could it help to get a picture of all the initiatives and where they are in the pipeline? Would it help to make sure we involve the teams and leaders who will need to execute on initiatives in the decision when to actually start them? It feels like we, the leadership team, are involved in every decision and are becoming a bottleneck for the organization. Could we perhaps agree on a threshold size of initiative/project where we get involved, and below which we empower our people? People often work together across departments, and every cross-department initiative is slower and riskier. Could we perhaps agree to work in cross-department teams on certain initiatives? Are there specific, ongoing, repeating cross-department patterns of work? Does it maybe make sense to arrange cross-department teams to work on those? Maybe give these teams outcome-oriented goals to pursue? Would it make sense to let people know what's the intent behind the work they're doing? Maybe measure progress towards outcomes when we review how initiatives are doing? How these teams are doing? Would it make sense to expect leaders to focus on building their organization and work with other leaders to build and develop the company? Maybe measure a leader's effectiveness by how effective their organization is, especially when they're NOT around calling the shots? It seems like we're oscillating between staying stuck in analysis-paralysis and spending a lot of time and money going in a direction without validating it makes sense. Would it help us sleep better at night to identify the most significant assumptions we are making and find a way to derisk them as cheaply and cost-effectively as possible? **Sometimes, the best way to pursue agility, especially at the organizational level, is to go underground**. We've seen how the mandated "Go Agile for Agile's sake" can become Agile Theater real quick. We can avoid that when pursuing Portfolio Agility, Product Operating Models, and whatever next big thing comes along. This advice won't work if a big consulting firm is driving your transformation. I'm sorry, and maybe I'll see you on the other side (you won't be the first, don't worry) **But if you're in the driver's seat, you can try this different approach, injecting helpful questions and patterns based on your context and needs.** Could you take a few minutes to think about it? What's the question you should be considering? What is the impact you are trying to achieve? Would you reply and let me know? Reminder - The Principles-based Agility Assessment can be a great source of questions for the guerilla agilist trying to help their team/organization improve its ability to innovate, get to market faster, satisfy its customers, and create new value. [It's now free through Cyber Monday.](https://yuvalagility.gumroad.com/l/principle-based-agility-assessment/blackfriday) ## PS I've used this underground approach several times through the years. I'm helping a pharma company's leaders pursue agility without "Going All In On Agile." If you want my advice on how to try this in your context, I'm one reply away. _Moving from agile theater to real business agility takes more than a framework. [Explore Business Agility advisory](/work-with-me) or [let's talk](/work-with-me)._

What Happened to Agile? And Where Do We Go From Here

Yuval Yeret — Mon, 25 Nov 2024 00:00:00 GMT

Let's be honest. These are "interesting" times for being an agilist. Whether you're in the "Agile is Dead" camp or not, it is clear that the movement is not well. Agile took over the software development world in a storm. As that happened, the demand for agile outstripped the supply. Agile became practice-focused. A commodity. Mainstream organizations didn't have the patience or desire to think from first principles. They preferred to implement agile rather than to evolve in an agile manner. The consulting and training industry obliged to provide products and certified people to support these products. Anyhow, Perfect storm. **Here's an alternative approach that you can use to get out of this mess or avoid it in the first place**: **Focus on agility rather than agile—principles instead of practices.** Ask yourself these questions: - Are we focusing on the end-to-end flow of value? - Are we continuously improving how we work? - Are we leveraging autonomy? Organizing people around value and empowering them? - Are we maintaining a sustainable pace? Of work? Of change? - Are we aligned? Are our goals and measures outcome-oriented? - Are we energizing people/teams? - Are leaders serving? Enabling? Nurturing? Focusing on systems? - Are we valuing speed and empiricism as a key way to derisk innovation? Change? Growth? **Which of these questions resonates the most for you? Why?** These are the questions I explore with organizations when we get together to either explore agility or accelerate/fix it. It's about establishing an agile-oriented intent that might pull in agile practices and frameworks based on context. **PS You can now leverage these questions for** conversations about your agile agenda. My principles-based agility assessment goes into more depth into these aspects of agility and helps you drive this conversation. [Get it for free here](/principle-based-agility-assessment)

The Two Word Check-in - Minimally Viable Daily Meeting

Yuval Yeret — Fri, 22 Nov 2024 00:00:00 GMT

What a difference through just two words. Two Words Check-in. I used it as a warm-up in a leadership session for a Boston-based BioTech. They liked it so much that they started using it as common practice. They started using it in their weekly Review/Retrospective/Planning sessions (Yes, they were using Scrum to develop the company; go figure) It became a highlight. Before you can talk work, accountability, results, and tackle conflicts, you need to maintain / warm up the social fabric. Here's an idea - Instead of talking about what you're all working on, share how you're feeling. Check-in with each other as human beings. (Two words check-in is one great way to do that, but whatever works) And that's it. (no 3 questions, no status, nada. Unless people really want to chat about something, or an issue emerges from the check-in) That's the most essential aspect of a Daily Scrum/Standup anyhow. Try it. ## Let me know how it went?

To Async or Not to Async

Yuval Yeret — Thu, 21 Nov 2024 00:00:00 GMT

So you identified a [meeting people won't miss one bit](/blog/developing-meetings-people-will-be-disappointed-to-miss) in your organization. Let's say it's a daily check-in. Standup. Scrum. The name doesn't change the fact that this is an often-mentioned issue people have with approaches such as Scrum, EOS, Scaling-up, SAFe. Want to improve this event? You can try increasing focus via visualization. Reviewing team structure to ensure people actually need to collaborate. Making sure the purpose and flow of the meeting are about issue identification and problem-solving rather than collecting status reports. Focusing just on exceptions to flow rather than everything. Those are all well worth trying. What I'm starting to encounter more and more frequently is a desire to reduce the amount of meeting time, regardless of meeting quality. You could (and many of you do) argue that if the meeting quality was really "Level 10" people won't mind them. Maybe. There's another possibility. Maybe by insisting on solving the issues with these meetings and sticking to them, we're enforcing our generational preferences on younger generations who don't share our preference for in-person meetings and formal communication. And its not just generational. People's preferences have changed (for example due to COVID19) and they are growing especially wary of virtual meetings. So, what would a Gen Z Scrum/EOS look like? Maybe I should go to TikTok/Insta and find out... The point isn't necessarily whether these meetings make sense: Sync, Async, or some hybrid. It is about evolving our ways of working in a way that balances empathy for the needs and wants of our "customers" (those using these ways of working) with the original intent. Async or not Async isn't the question. Evolve or Die is. If you are redesigning collaboration rhythms across teams, [Create a Business-level Operating System leveraging Agility](/work-with-me/create-a-business-level-operating-system-leveraging-agility/) is a practical next step.

Agile Marketing - Gateway to Wider Agility

Yuval Yeret — Wed, 20 Nov 2024 00:00:00 GMT

Agile marketing helps marketing organizations develop better campaigns faster. It helps marketers find sustainable pace and flow in the hectic marketing world by leveraging Scrum and Kanban. Team members act as "Mini CMOs" - thinking cross-functionally and are empowered to deliver results. BUT When there's a problem or opportunity requiring collaboration with other functions... Agile Marketing suddenly looks like an agile island in a sea of traditional management. Like agile development without DevOps. Agile Marketing is a great stopover. On the way to an even more exciting destination - Agile Business Teams.

Product Revisited

Yuval Yeret — Tue, 19 Nov 2024 00:00:00 GMT

I'm starting to wonder whether the current focus on Product Operating Models is a distraction from the real opportunity of applying Product Thinking. The whole conversation is about empowered product teams. There's minimal conversation about what's the product. Models inspired by Silicon Valley Big Tech companies focus on tech-heavy products. But what if the product is the business format? In [E-Myth Revisite](https://www.michaelegerbercompanies.com/product/the-e-myth-revisited/)d, Micael Gerber talks about developing your business as if you're preparing to make it a franchise (meaning the business format is systemized to the point that it is a product in and of itself). [Melissa Chi](https://suprainsider.substack.com/p/29-from-product-leader-to-coo-driving), a Product Leader who transitioned into a wider COO role, talks about [how her organization realized that the operational side of the business is also worth treating as a product](https://suprainsider.substack.com/p/29-from-product-leader-to-coo-driving). This makes so much sense, yet it is still uncommon in the product organizations I've seen. Business Leaders at a large FinTech already consider themselves owners and developers of the real business product. They are somewhat confused by the fact that there's now an additional product—the technology product (an artifact of a product operating model transformation driven by the technology organization). Here's my suggestion: When considering your product portfolio and where to apply a product operating model... Think about everything involved in creating the customer experience as the product.

Shaping Agility

Yuval Yeret — Mon, 18 Nov 2024 00:00:00 GMT

I'm honored to a community creator in [Shaping Agility](http://shapingagility.com) - a community dedicated to fostering workplaces where individuals are passionate about making a meaningful impact. It offers tools, insights, interventions, and a supportive network to empower leaders and change agents in achieving sustainable success. The community provides various resources, including podcasts like “Shaping Portfolio Agility,” which features in-depth interviews with executives and thought leaders on portfolio management, and “SPCs Unleashed,” a 21-part livestream series aimed at deepening knowledge of SAFe competencies.

Developing Meetings People Will Be Disappointed To Miss

Yuval Yeret — Fri, 15 Nov 2024 00:00:00 GMT

"How disappointed will you be if we won't have this standing meeting anymore?" Let's be honest - do any of you expect to see a "very disappointed" answer from the meeting participants? (If you do - let me know! I want to know your secret!) If there's anything competing with Agile in terms of how fast it's losing favor, it is Meetings. Meetings (call them Events, ceremonies, rituals) also play a significant role in what people dislike about Agile Frameworks such as Scrum and SAFe. There's another example, a somewhat funny one. Ask people whose company adopted EOS (Entrepreneurial Operating System), and few of them will be disappointed with the loss of the "Level 10" weekly meeting. This is ironic because the whole idea of the Level 10 meeting is that participants consistently consider it a 10/10 meeting. So what can we do? **Try making all of your standing meetings optional. Not just for individuals. But for the team to decide they don't want to have them.** What? The Scrum Team can choose to ignore their Sprint Planning meeting? yes. The ELT can choose to ignore the EOS "Level 10" weekly meeting? yes. The teams on the SAFe ART can skip PI Planning? yes. Can the Portfolio Leadership team skip a Portfolio Sync or Review meeting? yes. Here's what you might see... People have a say. They choose. They come as players, not as pawns. They stop following processes by the book and start thinking about the intent and the context and stop Whoever wants that meeting to happen needs to think hard about making it one people won't want to miss. ## They will need to start developing the meeting as a product people choose to use, an experience that works for them.

Continuously Deploying Points of View

Yuval Yeret — Thu, 14 Nov 2024 00:00:00 GMT

These are interesting times. If you’re an agile practitioner (like me) you’re navigating a lot of uncertainty. What’s the right language? “Should I talk about Agile? Avoid it? Take a contrarian view of it?” "Is Agility better than Agile? Worse?" "Should I talk about SAFe? Scrum? or better to talk about Product?" Agilists are struggling to stay relevant. And to fight harsh perspectives. It's a great time to develop (or polish) your point of view. Developing ANYTHING in a field of uncertainty requires iteration. Transparency, Inspection, and Adaptation. How can you do that for a point of view? You can write point of view slices. Even that process will make it transparent, and enable you to inspect it. You can also publish it. Get it in front of people. And inspect whether they engage with it. The more slices you get out there, and the more frequently you do it, the faster you might work through point-of-view options and converge towards something that works. Here’s the thing: Daily Emails. Continuous Deployment for Ideas. Used for developing your point of view. And testing it with yourself and your audience. ## What are some ways you’re getting faster feedback on your ideas?

Continuous Deployment - Vanity or Transformational Capability?

Yuval Yeret — Wed, 13 Nov 2024 00:00:00 GMT

It often feels like Continuous Deployment has become a bragging right for a technology organization. "We can deploy 13593 times a day." "A developer can deploy the product on their first day at work." "Our pets can deploy to production." Even more often, I encounter organizations that don't understand the intent behind being able to deploy continuously. Few organizations need continuous deployment capabilities from a time-to-market perspective. So why is it so crucial? Because integrating and deploying every small change dramatically reduces the length of our feedback loop. We talk about Empowered Product Teams. Empowered to deliver outcomes. But in an environment of uncertainty, we don't know for sure whether a certain product development will indeed deliver the expected outcome. So we need to try, inspect, and adapt. This is where the feedback loop is crucial. Without continuous deployment, it might take us weeks to inspect and adapt. We will work from assumptions, requiring us to plan and specify more. Product Operating Models are cool. But without the ability to close feedback loops. To make a decision and gauge its outcome. Whether it creates the experience and behavior we hypothesized It's a Product theater. On the other hand, if you can continuously deploy but are NOT using it to close feedback loops, that's also a theater. And what if you're designing razors? Molecules? Laundry care formulas? Craft beer? The intent is still the same - You want to close fast feedback loops. You want genuine feedback on your latest decision as quickly as possible. So you 3D print the latest increment of the benefit bar for your razor, formulate a trial run of the beer/laundry care formula, and get it in front of customers—not to make money, but to learn and adapt if needed. Here's the thing Like any other practice - it's all about the intent. Why is it worthwhile doing this? Understanding the intent helps us adjust the practice to the context. This is especially useful when [using a practice like continuous deployment outside of its usual context](/work-with-me/create-a-business-level-operating-system-leveraging-agility). https://youtu.be/9NCu\_wWCZBs

Scaling Your Product Org w/ Product Operations

Yuval Yeret — Tue, 12 Nov 2024 00:00:00 GMT

Something clicked for me over the last couple of weeks as I've been sharing my reflections on what I'm seeing in the trenches when it comes to the journey towards Product Organizations and Product Operating Models. As a reminder, The vision of the Product-oriented organization is to have product teams: - Fully aligned around outcomes - Focused on what truly matters - Collaborating cross-functionally - Equipped with data-driven insights to make informed decisions This is a great north star. But a challenging transformation. Especially in organizations new to the Product world (think classic IT/internal software/beyond software). Moving from managing tasks and backlogs to managing outcomes. Owning Products rather than Projects / Technologies. Providing Product professionals with access to the data and insights they need to iterate towards valuable outcomes. What I've seen help is when organizations have people who enable, steward and promote product-oriented thinking and ways of working, and provide the platforms/tools that make it easier for product professionals to work this way. In established Product Organizations, especially in the Tech world, this is known as Product Operations — optimizing structure, processes, and tooling to enhance the Product Management experience and drive innovation with fewer distractions. Here's the thing: If you're leading your organization's journey from Project to Product, [Product Operations](/work-with-me/bring-clarity-and-traction-to-your-product-organization-with-product-operations) capabilities is one area you should be learning about and thinking through as part of the structure of your Product organization. PS I think the future of Product Operations is even more interesting. As companies start to [use product thinking to develop the company](/blog), there will be even more demand for enabling people to think and work in product ways of working.

Developing your Product-oriented Portfolio Using a Product-oriented Approach

Yuval Yeret — Fri, 08 Nov 2024 00:00:00 GMT

Three members of a PMO are asked what they are doing: - The first says, **“I’m updating processes to align projects with product teams.”** - The second says, **“I’m shifting our portfolio approach from projects to products to enhance delivery and value focus.”** - The third says, with conviction, **“I’m transforming how we invest, plan, and deliver value by focusing on products rather than projects, enabling our teams to be more adaptive, customer-centric, and capable of delivering lasting impact for our business and customers. I’m helping build a product-oriented mega-lab.”**[(inspired by the story of 3 bricklayers…](https://sacredstructures.org/mission/the-story-of-three-bricklayers-a-parable-about-the-power-of-purpose/)) Since we’re talking about a Product-oriented Portfolio, it makes sense to treat developing it as a Product Initiative. Making sure we’re focused on outcomes, rather than checkboxes. We might use patterns and frameworks (such as a Kanban Board, OKRs, and Portfolio Reviews), but we should start with why. This will help steer us in the right direction and ensure our intervention evolves in a way that improves its fit for purpose. It’s also leadership by example. This is the way we expect other portfolio initiatives to be managed. Like product initiatives focused on outcomes rather than projects focused on a predetermined scope. So, the first thing to do will be to establish what’s broken. What are the pains in how the job of managing the portfolio of technology investments is currently being done? Using Evidence-based Management, we could look at areas like: - Are we happy with the value we’re creating across all our products? One interesting question at the portfolio level is whether our customers feel they’re working with a disjointed set of products/capabilities or are they getting a seamless experience? - Are we happy with the outcomes generated from what we deliver? Do we even know whether our customers are happy? Do we even plan outcomes? Measure them? - How satisfied are we (and our stakeholders) with our ability to innovate? - How good/bad is our time to value? - Are we aligned to our business strategy? Are we working on what will move the needle from a strategic perspective? Do we know? Can we actually double down on these things? - How hard is it for people to actually deliver business outcomes? How many hoops do they need to jump through to get meaningful things out the door? - How happy are we with our ability to adapt to shifting business needs and realities? - Are the things we’re currently measuring helping drive the right behaviors? Or incentivizing undesired ones? - Are people motivated and energized by their work? Do they understand and connect to the bigger picture? Then, describe an outcome hypothesis. What are we hoping to see? What’s going to look different for all the various stakeholders? And what is going to be the impact of this changed environment on our business? Describe some leading indicators - How will we know we are heading in the right direction? [How will we know we’re not](/blog/hacking-your-way-to-an-evidence-informed-mindset?utm_source=rss&utm_medium=rss&utm_campaign=hacking-your-way-to-an-evidence-informed-mindset)? Try to weave the problems/opportunities you’re seeing, the dream state, and the approach you have in mind into one coherent story. So, are you a [cathedral builder](https://sacredstructures.org/mission/the-story-of-three-bricklayers-a-parable-about-the-power-of-purpose/) by now? PS Here are some tools you can use to help you in this exploration of the problem/opportunity - - [A3 Document](https://blog.crisp.se/2009/09/23/henrikkniberg/1253687880000) - [Objectives and Key Results](/blog) - [Value Proposition Canvas](https://www.strategyzer.com/library/the-value-proposition-canvas) - [Lean Canvas](/work-with-me/steer-towards-product-market-fit-with-lean-startup-coaching) - [SAFe Epic Hypothesis](https://scaledagileframework.com/epic/)

Embarking on Your Product-Oriented Lean Portfolio Management Journey

Yuval Yeret — Thu, 07 Nov 2024 00:00:00 GMT

Are you at the stage where traditional portfolio-level processes and behaviors present the most significant impediment to agility? I see this often. The organization spends six or seven-figure amounts on an agile transformation. Teams and Teams of Teams are working in Agile/Scrum/SAFe. Still, the promised land of outsized value creation and improvement of time to market (rather than flow time of stories or “features”) is elusive. Looking at the conversations around budget, governance, and driving your significant business initiatives, agility is the last term that comes to mind (bureaucracy and large ship struggling to maneuver are more apt descriptions) You envision finding an organizational operating system that orients around outcomes, where the right people collaborate closely with each other, where people naturally and easily integrate and experiment, and where there’s a goldilocks mix of alignment, autonomy, and guardrails. **You decide it's time to [bring agility and product-orientation to the portfolio level](/work-with-me/scale-agility-leveraging-the-scaled-agile-framework/lean-product-portfolio-management).** What does that look like? Let's discuss transforming your IT portfolio from a feature factory managing scattered investments to creating a product-oriented mega-lab that drives growth, value, and resilience. **You can think about the journey to a product-oriented portfolio in four stages: Crawl, Walk, Run, and Fly.** Each stage helps your organization evolve towards agility, evidence-based decision-making, and continuous alignment. **Crawl:** You start by recognizing that you already have a portfolio of investments, even if it's not formalized. In this stage, you start to understand your portfolio and the flow (or lack thereof) of your significant investments. **Walk:** Begin actively managing the flow and shaping demand. (Saying No, or not yet) It’s about turning a collection of projects into cohesive products—creating an intentional balance between technology and business investments. Starting to have conversations around which decisions to manage at the portfolio level, and which to empower product teams to have. **Run:** Now, it's about aligned autonomy. Teams are free to innovate, while strategic goals keep everyone focused on the outcomes that really matter. Stable funding decoupled from product cycles helps teams thrive without constant budget concerns. **Fly:** Finally, you’re in full agility mode—treating your entire business like a product. Lean Startup principles guide how you adapt and grow, and every aspect of the industry evolves in response to real-world feedback. **This journey isn’t about frameworks or processes—it’s about behaviors.** In the early stages, it is focused on establishing flow. Then, it is about reorganizing around value and outcomes and eventually being evidence-informed. Where are you in this journey? Which behaviors are you seeing? What are the next ones to focus on? **PS What if there was a way to navigate the portfolio agility journey, without falling into the trap of a prescriptive itinerary that so often ends up at the (agile) theater? That would be nice, right?** If this is your challenge, see [Portfolio Agility](/work-with-me/portfolio-agility/) and [contact me for a clarity conversation](https://calendar.google.com/calendar/appointments/schedules/AcZssZ1oyzEgQC72Vn3BahuIujWuWDiHhazgSuq97w4awDqO-OUWsvXZ-znuwte22yvLQMg1jWuNQZVw?gv=true). https://youtu.be/ghN5fHv3Ikw

Stop Focusing on Utilization. Start Focusing on Flow

Yuval Yeret — Wed, 06 Nov 2024 00:00:00 GMT

Does it make sense to aim for 100% utilization across the organization? Is that efficient? Whether it’s an ad agency, a factory, a product development organization, or any organization - it has a constraint. The constraint/bottleneck should be optimized, but other areas of the process shouldn’t aim for 100% utilization since that would create waste and overload. For example, let’s say client approvals are the constraint. If everyone else aims for 100% utilization, tons of “inventory” would be waiting to be approved. Instead, the [Theory of constraints](https://www.tocinstitute.org/theory-of-constraints.html) (which was born in the manufacturing world but its principles apply for knowledge and creative work) would say to find the constraint and focus on it - by subordinating other steps to its pace, helping it, and eventually elevating it. For example, we could make it easier for the client to approve, choose easier clients to work with and use slack in other areas to deal with this issue. One good way to apply this thinking is to manage end-to-end flow (via something like a Kanban board) across functions and disciplines. But first, you have to learn to see flow. In agencies, tracking the flow of client deliverables is often a good place to start. And back to utilization—one nice trick is to move from optimizing utilization of people/teams to optimizing utilization of deliverables—minimizing the amount of time the deliverable sits as idle inventory waiting to be worked on. (This is also known as Flow Efficiency.) Here's where you can start then: - Identify the 1-2 key business processes you want to focus on optimizing/fixing - Decide what will be flowing across the value stream (e.g. Deliverables, Customers, Projects, Requests, Campaigns, Plays, etc.). Tip - This isn't necessarily the day-to-day tasks - it's often work that will flow end to end in a few weeks. YMMV - Map out the key steps in the flow - Create a Kanban Board where you will see and manage the flow as part of your regular management cadence across whatever functions/disciplines/people are involved. Look for bottlenecks and constraints and focus your improvement conversations around them. - Measure [Flow Times and other flow metrics](/blog/4-key-flow-metrics-and-how-to-use-them-in-scrums-events) and look for interesting patterns.

The Pricing Page for Your Change Product

Yuval Yeret — Fri, 01 Nov 2024 00:00:00 GMT

You've seen it before. The pricing page. With the three options. Silver. Gold. Platinum (nobody wants bronze) DIY. DWY. DFY. Starter. Professional. Enterprise What if you tried using "Pricing Options" when selling/marketing internal change? Revolutionary. Evolutionary. Safe. Extreme. Fast. Meeting-heavy. Meeting-less. Invitation-based. Mandatory-change based. Pull. Push. Here's the thing Multiple pricing options create choice. Choice gives control. Control lowers resistance. (Think of it as another hack in the ["open space agility" / "invitations-based change"](/blog/safe-invitations-part-3-3-combining-open-space-agility-and-safe) toolbox) When our change clients see options, they feel empowered. Instead of looking for alternatives, they pick what feels “just right." More options = less pushback + more change. (BTW, Too many options = confusion + less change... ) Can you create a "pricing page" for the change/transformation you're selling to your organization? Can you do better than Good. Better. Best? Can you come up with descriptive names focused on outcomes? risk? other aspects of the change? Remember - context matters. What's best in one place is barely good for another, and vice versa. ## PS The idea for this post came up while I was listening to [The Perils of Good Better Best pricing](https://2bobs.com/podcast/the-perils-of-good-better-best-pricing) yesterday.

Navigating Strategic Change using Breadcrumbs (A Halloween Story)

Yuval Yeret — Thu, 31 Oct 2024 00:00:00 GMT

Meet change approaches F and S. S is a revolutionary change for people. It requires new roles and totally new ways of working. It is shock therapy. It requires such a leap that people often resort to faking it because it is so hard for them to change. F is evolutionary. It starts with where you are. It shows you how you’re working. It nudges you along the way. It is so comfortable and safe that it's tempting to settle down and rest instead of moving toward the destination. Both S and F require careful navigation of the change path and proactive leadership and guidance. A concept that can help for both S and F is what Roger Martin refers to as [Breadcrumbs](https://rogermartin.medium.com/strategic-breadcrumb-spacing-6273ae50983e) (Think Hansel and Gretel ). Breadcrumbs help us see the next step, make S safer and clearer, and light the path for F. Many Experts and Early Adopters don’t need the breadcrumbs. The path is clear for them. They sometimes find breadcrumbs repulsive and prescriptive. They have a particular distaste for specific safe havens along the path. Here’s the thing, though… Change is a Product. It should be customer-centric. Designed for the context. There are different types of customers (or people going through change). Many of them do need breadcrumbs. It's not the breadcrumbs that are evil. It's the witch (that is hiding the breadcrumb trail)! ## Happy Halloween !

Using the PMF Survey to gauge Company Fit For Purpose

Yuval Yeret — Wed, 30 Oct 2024 00:00:00 GMT

_How would you feel if you could no longer work the way we work here?_ - _Glad_ - _Not Disappointed_ - _Somewhat Disappointed_ - _Very Disappointed_ Sean Ellis, the OG Growth Hacker, came up with the [PMF survey question](https://pmfsurvey.com/), which has become one of (if not the) established ways to gauge Product Market Fit: If more than 40% of your existing customers answer “Very Disappointed,” you are well on your way. Y**our way of working is also a Product.** It also has customers. They’re called team members, associates, employees, whatever name you want to use. The Structure, Process, Culture, and Tools are all part of this Product. **Would you dare run the PMF survey about the Company as the Product?** One interesting dynamic in the case of the Company is that the answer might shift significantly over time. Have you ever spent time at a Scale-up? There’s often this feeling of losing traction, even stalling. There was once energy, joy, and purpose. Everyone knew everything going on, and the team was small, aligned, and powerful. Post-PMF the team is growing fast. The afterburner is on. More people join, Leaders take over functions, and siloes are formed. New grown-up processes are added. Sometimes they work. Sometimes they don’t. You almost don’t need to run the PMF survey on the company at that point. It’s pretty evident that most people wouldn’t be disappointed if the company could no longer work this way. Some would even be Glad. Nobody would be very disappointed. So what do you do? **You start developing and iterating your Company as a Product, working to regain PMF.** [This is also what I do](/work-with-me/create-a-business-level-operating-system-leveraging-agility). I help leaders see, develop and iterate their organizations using product thinking and techniques.

AARRR Pirate Metrics for Change Adoption

Yuval Yeret — Mon, 28 Oct 2024 00:00:00 GMT

"We trained 1359 people!" "we transformed 127 teams" Enough with the vanity metrics. Ever wonder how your change initiative is REALLY doing? Think of your organization as an internal market for the change. Consider [Pirate Metrics (AARRR)](https://www.productplan.com/glossary/aarrr-framework/) to see how your change "Product" is doing in this market. **Acquisition (or awareness) –** are people discovering our change? How effective are we at acquiring new interested internal customers for the change? **Activation –** Are these people taking the actions we want them to? Are they starting the change process? **Retention –** Are our activated changers continuing to engage with the change? **Revenue –** Are we making money from user activity? What does this mean in the world of change? Revenue stands for "Value Extraction" which should be measured in terms of change outcomes (not just activity). **Referral –** Do changers like the change enough to tell others about it? How often do we get inbound requests to change from people that weren't on our radar yet? If you want to go the extra mile you could ask changers the [Sean Ellis PMF survey](https://pmfsurvey.com/) - “how would you feel if you could no longer use this new changed way of working?” and measure the percent who answer “very disappointed.” (an interesting sidebar discussion is whether the PMF threshold of 40% applies for internal change as well. Or should we aim higher? lower? WDYT?) **How about an Example** Let's say we are trying to get people to [change the names of their work artifacts to reflect outcomes.](/blog/its-all-in-the-name) We are focused on a change audience of everyone in a Product discipline in the organization. **Acquisition (or awareness) –** How many Product people are aware of this concept? we could use internal analytics to see how many of these people opened this new guidance, showed up for an info session, etc. **Activation –** How many of the Product people started naming items using an outcome orientation? This is a bit harder to measure at scale. One technique we could use is to include a gauge for each work artifact where the product person indicates whether the name is outcome oriented in their view. **Retention –** Do these Product people continue to rename items? to name new items using an outcome oriented name? "**Revenue" –** Are we seeing positive outcomes from these new names? Here is where we would have to be clear with our outcome hypothesis from the get go. As part of the change plan we will lay that out and consider it before actually going through the change. **Referral –** Do we start to see more and more Product people showing awareness, getting interested, even without us reaching out? Can we measure somehow when people forward the "playbook" to others? As you can see, the concepts apply nicely, even if the telemetry to measure change might require some creativity. One other thing you can try is to consider AARRR metrics as leading indicators when you're designing the change / intervention. While "Revenue"/Outcome is what you're really aiming for, the AARRR funnel can help lead to outcome while avoiding vanity metrics. So ... Think about a change/intervention you're currently advocating for in your organization What would the Pirate Metrics tell you? Would you dare asking the PMF survey question? https://youtu.be/xJzaKeCYVhg --- _Improving how your SAFe implementation actually delivers speed and outcomes — rather than process overhead — is a core part of how I work with scaled organizations. [Explore SAFe advisory](/work-with-me/scale-agility-leveraging-the-scaled-agile-framework) or [let's talk](/work-with-me)._

From Inclusive to Focused Goals using Even Over statements

Yuval Yeret — Thu, 24 Oct 2024 00:00:00 GMT

Do you ever feel like your goals are too inclusive? Being inclusive is essential for culture but not so good for setting goals. You want your goals to mean something. They shouldn't be an excuse to enable you to continue to spread your attention all over. A question you can ask about your goal/s is "What are the investments we WON'T be making as a result of these goals?" (This is my favorite question to drop into a group of Portfolio Leaders trying to figure out their Strategic Themes / OKRs...) I added this question to the worksheet I use for drafting and considering Goals/OKRs. (If you want me to create a template of this worksheet, reply and let me know...) Another technique you can try is "[Even Over](https://kb.founderculture.net/public/posts/utb4drb0)" statements. "Improved Customer Onboarding Experience **Even Over** New Features" "Plug Churn **even over** new logos" ([The Agile Manifesto for Software Development](https://agilemanifesto.org/) is an excellent example of even over statements) So... Consider your current Goal/s. Whether they are Product Goals, Strategic Themes, Outcome Hypothesis for an Epic / Feature. Does the goal enable trade-offs of what's in/out? Is it clear what's really important? Can you use an "even over" statement to help clarify?

Product Operating Model for Shared Services and Business Operations Teams

Yuval Yeret — Thu, 24 Oct 2024 00:00:00 GMT

While the Product Operating Model focuses on developing new Products, it has implications and potential benefits for the teams operating the business and supporting these products. (These work in the Operational Value Stream, as defined in SAFe.) ## Improving the Interface between Product Development and Business Operations The handoff point between development and operations is a common source of frustration, delays, and rework for everyone. Business Operations / Shared Services teams are surprised; their operational considerations are much harder to address when they come when the solution is already built, and everyone is hoping to celebrate and move on. Reducing this friction requires involving operations early, making dependencies visible, and optimizing end-to-end flow metrics. Late-stage handoffs are a predictable source of rework and delay. (Note: One specific example is GTM (Go to Market) activities. GTM Teams simply LOVE it when they're brought in after they have zero opportunity to shape the product. This is a classic question in the relationship between Product and Marketing. There's more to say about this specific example, but the principles we outline here are a good start) The DevOps approach was created to help streamline and improve this handoff/interface. While developed in the context of Technology Operations, the principles apply to any sort of operational work: - Understand how work **Flows** through development to operations. Notice bottlenecks, patterns, and start to think about how to create leaner more streamlined flow of value. This is achieved through managing work such as Features through an end to end Kanban system that includes all of the operational steps needed before operations business as usual. - Move beyond “us vs them” to a **Culture of shared responsibility** for both innovation flow as well as business uptime, quality, etc. This is achieved through shared KPIs, bringing people closer together through more frequent interactions and deliveries and other interventions. - **Automate** in order to enable faster flow and feedback **-** the goal in the Product Operating Model is to deliver frequently, in order to learn and steer continuously, which is crucial in environments of uncertainty / probabilistic development (which is often the case for new product/capability development). Delivering frequently burdens business operations if there’s a heavy manual transaction cost as part of the delivery process. Automation of as much as possible in the path to operating capabilities/products in production is a key enabler for continuous or more frequent delivery, and the Product Operating Model. - **Measure Flow, Quality, and Value -** as mentioned above, The Product Operating Model depends on feedback, through evidence, to inspect and adapt. Measurement of flow helps inspect and adapt the process. Track flow, quality, and outcome impact. The right mix helps teams improve reliability while still evolving services toward higher strategic value. In addition, strong measurement enables more confidence in changes being introduced, which in turn enables more frequently introducing changes. - **Recovery - reduce risk & preserve value** - finally, strong ability to recover from mistakes through fast turn around of fixes, enables moving faster and making changes more frequently. To dive deeper - check out [SAFe's CALMR approach](https://scaledagileframework.com/calmr/) and [Gene Kim's Three Ways](https://itrevolution.com/articles/the-three-ways-principles-underpinning-devops/) ![](/assets/images/blog/archive/recovered/product-operating-model-and-shared-services-business-operations-teams-1-ad_4nxfcjxeswhgll_ok6ntdp_chhswxb7ishkdp3jkeapyugl56ghbwbrsz3euwhrizikqa__gt5jieqf_rpzijcdnwtddvalfhapcc96ag1ab4e12mvlmb47yt8jwbcibmklmuboykkbphkzzd7_cbcc2onal4.png) Again, all these principles were created in technical operations but can map nicely to business operations. Specific questions to consider: - What’s the appropriate way to model business operations readiness work in the Kanban systems ARTs use to manage the flow of Features? - What’s the best way to engage business operations representatives in the work of the Development Value Streams/ARTs? - During activities such as PI Planning where the upcoming quarter is planned and dependency on partners such as business operations can be considered and taken into account? - To weigh in on refining a Feature into Stories? - Capture business readiness acceptance criteria as part of the non-functional aspects of the Features/Stories? - Join Planning Sprints where business readiness interaction is needed? - Review Sprints to provide feedback and steer from an operational perspective? - What are the biggest challenges for more frequently delivering through to the business? What are some manual steps that could be automated or simplified or otherwise improved to reduce the overhead and enable higher frequency? - What do we need to measure to enable and streamline ongoing business operations? Mainly to reduce the risk of accepting changes more often? - How can we streamline recovery from business operational issues - mainly resulting from new deliveries but not limited to that context. ## Improving Business Operations Flow Another question that often surfaces is whether it makes sense to use the Agile ways of working of the Product Operating Model in business operations. There’s a big difference between developing services/products and running/operating them. Developing products is almost always a probabilistic endeavor, rife with uncertainty and discovery. Agile/Adaptive ways of working are designed to help derisk and maximize outcomes in this context. This is a core part of the Product Operating Model (also known as Agile Product Operating Model). Running/operating services could be both probabilistic and deterministic. Sometimes even in the same type of work. Take cybersecurity for example. Much of cybersecurity operational work is deterministic - routine vulnerability scanning, configuring security products for new users / services, System patch management. There are spurts of probabilistic work with higher uncertainty - think threat hunting, incident impact assessment or zero-day vulnerability management. Let’s take another example - legal operations. Drafting/reviewing standard contracts, regulatory reporting compliance are a few examples of deterministic operational work. Handing a regulatory investigation, assessing legal risk exposure for a new product/capability, evaluating compliance in emerging regulations (e.g. cryptocurrency) are some examples with more uncertainty. Why is this important? Deterministic work can be managed using a “factory”, output-focused flow approach. There’s still value in understanding and improving flow, shaping demand to available capacity, reducing juggling, delays, and rework. But there’s not as much of a need for empiricism and the tight feedback loops provided by agile ways of working. **Don't rush to copy-paste ways of working from product development to operational work. Shared services teams don't always need to adopt Scrum to work in a product operating model. Choose ways of working based on uncertainty and flow characteristics. Some teams benefit most from Kanban and flow management, not sprint mechanics.** The first question an operations team should ask themselves is what’s the balance between probabilistic and deterministic work and use that to determine whether it makes sense for them to fully use agile ways of working such as Scrum Sprints, or to focus on understanding and improving flow using, for example, a Kanban approach to work management. Even deterministic teams benefit from an inspection and adaptation loop for their working methods. Techniques such as a cadence of retrospectives work well to help teams improve their processes, teamwork, and overall outcomes. ## Improving Business Operations Capabilities / Effectiveness Inspecting and adapting their work can also result in ideas for innovating business operations capabilities. What can we do with these ideas? If they require product capabilities, Introduce them into the intake process for the Development Value Streams and have representatives of business operations support/guide their development as stakeholders, or even join the team working on them to help hands-on in the trenches. If they don’t require product capabilities, Apply the Product Operating Model within business operations by creating a mini-development value stream/team. Product Ownership prioritizes a backlog of ideas and explores/develops/deploys these ideas into the operation. Some questions operations teams can ask: How can we productize our services? What can we automate? What can we systemize and expose as self-service? There might be many opportunities – which of them is most valuable? What would create the best outcomes for the people you are serving? What would let you serve more people more effectively? Once teams start to think this way – Many aspects of Product Thinking and a Product Operating Model suddenly become useful. Agility becomes a helpful way to navigate the uncertainty of which self-service capabilities will be consumed and which will be rejected... Even in this mode btw, the team would probably work on a mix of "run the business" operational work and "developing the business" improvement work. Be careful where and how you apply ways of working to support these two very different work styles. --- _Agile marketing creates real pipeline impact when practices match the team's actual rhythm. Explore [Agile Marketing advisory](/work-with-me/agile-marketing-workshop) or [reach out](/contact)._

It's all in the Name

Yuval Yeret — Tue, 22 Oct 2024 00:00:00 GMT

Shifting from projects/solutions to a product/outcomes mindset is hard. And the Names we use for our Epics / Features / Stories make it even harder. Too often than not, those names are a relic of the original ask, which is typically of the "build it and they will come" nature. Even as we work on exploring the story, feature benefit hypothesis, and epic bet, we often keep that original name. Everybody already knows that name, so it's easier. **But unhelpful.** It reinforces solution/HOW thinking. It focuses on activities or outputs rather than outcomes. Want an example? Look at Google's "**AI Overview**". I don't know if that name was used internally while the feature/initiative was being considered and developed. Let's imagine it was. **AI Overview** is the solution. It is the result of exploring the insight that users are increasingly asking complex, multi-step questions that traditional search formats struggle to address efficiently and the hypothesis that it could assist users in quickly finding relevant, high-quality information and engaging with more diverse web content. **"Easier and faster answers to complex searches/questions"** could be an **outcome-oriented name** that keeps everyone focused on the outcome and maintains optionality about the solution. So ... For the things you're working on right now (whether they're Portfolio Epics, Features, PBIs, or even Projects!) ... Try using names that describe the intended outcome/experience. Use these names to reinforce the product/outcome orientation mindset to all stakeholders. Use these names as a constant reminder that the WHAT/HOW might shift based on what you have learned. If you want help applying this outcome-oriented naming discipline in your portfolio and product work, see [Figure Out Your Product Operating Model Strategy](/work-with-me/figure-out-your-product-operating-model-strategy/) and [Portfolio Agility](/work-with-me/portfolio-agility/).

Product Ownership - To Be Or Not To Be - The Product Leader's bind

Yuval Yeret — Mon, 21 Oct 2024 00:00:00 GMT

Meet Alice. Alice is the CPO at BuzzCorp. As BuzzCorp tries to move from "Agile Theater" to product-oriented agility, Alice is trying to figure out the appropriate structure for the Product organization. Beyond the Product Managers in her group, BuzzCorp also has about three times as many Product Owners working closely with its Agile Teams, which are mostly oriented around systems, components, and layers of the BuzzCorp technology stack. Alice sees the Product Managers as driving strategy. But she also wants them to be engaged in continuous discovery, development, and validation loops to bring their strategic vision to reality. **Product managers SHOULD take on the responsibility of product ownership for their product.** **Whether they're excited to do so is an excellent sniff test for whether your team topology is product-oriented** Alice and her team aren't very excited to take on the product ownership role with the way the teams are currently structured. Sniff test - it smells... How do we help Alice and her team out of this bind? Alice will need to work with technology/engineering/IT leadership to develop a product topology based mainly on empowered product teams. This often means shuffling teams from systems/components to product-oriented teams. Other patterns include identifying an internal platform and considering it a product, with the appropriate empowered product team and ownership that ensues. In other cases, the Product is quite big - and it's unclear how to split it into sub-products each with its own empowered decoupled product team. While not trivial, that is a crucial exercise to explore. (If you're interested in my spending time on some techniques for slicing products reply SLICE...) As a pragmatic compromise, Alice can organize the groups working on these larger monolithic products into stream-aligned teams (also known as Feature Teams) that can deliver a feature on this product but don't necessarily own the end-to-end product lifecycle/outcomes. Each of these teams would be empowered to hit a certain objective/goal out of the park by exploring what features are needed and trying different approaches until they achieve the objective (or go back to the Product level with a suggestion to reconsider the goal). Even though they don't own a product, Alice realizes that these teams will benefit from having a product management professional working closely with them and providing product ownership guidance and direction to the team. She decides that this is an excellent opportunity for junior product managers in the product organization. So... What does your team topology look like? Is it product-oriented? A good question to ask is whether a real Product professional would thrive if they took on the product ownership role for each of the teams. How could you tweak the topology to make it more Product-oriented? What would need to be true for that new topology to work? What does the runway towards making it real look like? ## What is the 15% small intervention you can try to drive, as a Product Leader, to create more empowerment in a few more areas of your product organization? _Designing and evolving a product operating model is one of the highest-leverage things a product leader can do. [Explore Product Operating Model advisory](/work-with-me/figure-out-your-product-operating-model-strategy) or [let's talk](/work-with-me)._

"Transformed". Yet still the same. An All Too Familiar Agile Story

Yuval Yeret — Fri, 18 Oct 2024 00:00:00 GMT

Picture BuzzCorp (Many of you won't have to use too much imagination). They've invested significant efforts in developing software and products in an agile manner. They formed agile teams (but a deeper look shows those are the existing component/functional teams using agile methods) They manage Features/Stories in JIRA/ADO (but those are the functional slices that these teams can accomplish, rather than useful product slices) They've transformed. There's some flow of "stories", maybe even "features". 3 questions are asked every day. velocity is counted. They are doing agile. At the team level. But. Products still require collaboration across many teams, and typically, many months pass before something potentially valuable is integrated and available for customer feedback, not to say release. BuzzCorp Product Managers don't understand why they're expected to become "Product Owners" of these teams. So, the engineering/IT organization assigned "Product Owners" (who create stories, manage the backlog, and manage team interactions but don't own a product or even product-level outcomes). BuzzCorp adopts an agile scaling framework to help them manage this crazy web of dependencies. (But once again, they ignore the intent and principles and take the easy way out) BuzzCorp Product leaders think Agile is a sham. They start looking at an alternative. PS What will happen when they install a product operating model (you can probably guess ...)? https://youtu.be/NAYAINQmC18

Breaking the SAFe Season 1

Yuval Yeret — Wed, 16 Oct 2024 00:00:00 GMT

Is SAFe good? Is SAFe agile? What are SAFe's strengths? Weaknesses? How does SAFe see the Scrum Master and Product Owner roles? What are the benefits and challenges of the PI Planning practice? Ryan Ripley and I recorded ["Breaking The SAFe](https://youtu.be/yp8yBfGRopY?si=3eUBqbQo-6GuUnvUhttps://www.youtube.com/playlist?list=PL9uyGDiy_ChWPZLFX9hM3wtp8m8uBwrcy)," a series of videos deconstructing some of SAFe's intent and choices, especially those that seem to clash with Professional Scrum. Do you want a Cliff's Notes version? Here's an Audio Overview (AI-Generated by Notebook LM): Here's the complete Breaking the SAFe series if you still prefer to listen/watch humans: https://www.youtube.com/playlist?list=PL9uyGDiy\_ChWPZLFX9hM3wtp8m8uBwrcy

Spectrum Healthcare - Organizing around Patient Outcomes To Amplify Business Impact

Yuval Yeret — Tue, 15 Oct 2024 00:00:00 GMT

**Overview** Spectrum Healthcare, a multispecialty medical practice in Maine, wanted to improve operational efficiency across surgical operations, quality, marketing, clinical operations, physiotherapy champions, compliance, medical staff services, billing, and IT. IT, clinical and operational leaders aimed to enhance collaboration across departments and improve their ability to drive operational changes effectively. **When/Why** Spectrum was looking at several key initiatives - Consolidating/Evolving their network of clinics as they grow, Going digital with an electronic medical record, introducing and extending new models of care such as telemedicine and enabling radiologists to work remotely. The urgency for improvement skyrocketed during the COVID-19 pandemic which obviously accelerated the need for several of these business shifts and created some additional challenges and opportunities. **Options** Before adopting Agile, Spectrum Healthcare had relied on a traditional project management method to implement changes. However, this approach of managing fragmented communication and collaboration between IT and operational team suffered from delayed feedback, rework, frustration, missed timelines and mediocre outcomes, ultimately affecting patient care and work experience for everyone involved. Spectrum realized it needs to pivot much more swiftly than its current collaboration structures and ways of working allowed for. It chose to work with Yuval due to his unique expertise and experience applying agility at scale beyond the boundaries of IT. **Success** Spectrum Healthcare leaders set their sights on faster time to market with better outcomes on their strategic cross-cutting initiatives - with leading indicators being improved collaboration between IT and operational leaders and faster integrative feedback loops as these business initiatives were being developed. The first notable achievements were the completion of a clinic consolidation and the rapid deployment of telemedicine services during the pandemic. Teams also shifted focus on high-priority projects and became more predictable. **Path to Success** Spectrum chose to use agile to tackle these cross-functional business initiatives. In order to work effectively on several initiatives that included synergy and shared expertise, we decided to leverage a Scaled Agile Framework (SAFe) ART construct. The engagement started a strategic workshop where IT and business/operational leaders learned about SAFe (using Leading SAFe), explored and created a blueprint for how Agile principles could be applied to their specific context. A Value Stream Identification workshop followed, mapping out the Operational Value Stream (the patient journey) and the Development Value Stream (improvements to that journey). We launched an Agile Release Train (ART) with cross-functional teams working on key initiatives, including telemedicine and remote radiology access. **How We Helped** ## Our work together included training leaders, identifying appropriate way to organize around value and collaboration, and facilitating and supporting initial cycles through the new way of working, enabling inspection and adaptation to tweak the approach to Spectrum's needs.

Searching for Products in the Healthcare Provider World

Yuval Yeret — Tue, 15 Oct 2024 00:00:00 GMT

If you're a healthcare provider, what is your product? This question surfaces when these organizations try to adopt a Product Operating Model or move from project management to a product-oriented organization (and yes, there's quite an overlap between these two ) I like to consider this from the perspective of the customer—in this case, the patient. The product is an experience—a fast, convenient, high-quality treatment with minimal friction—not just the treatment itself but the whole experience around it. This definition unlocks the potential to create empowered cross-functional product teams accountable to patient experience. In a small provider, this might be one team involving people from different areas of the organization. In a larger provider, this might involve multiple teams, each structured and empowered to own a patient experience (e.g., the telemedicine experience, the clinic visit experience). Some teams will be long-standing, owning and improving a product experience over time. Some teams will be formed to create new patient experiences or to drive dramatic change across experiences. Once you organize empowered teams, the next question to tackle is how they could collaborate in a way that lets them iterate through fast feedback. What does an increment of the patient experience that can be inspected and used for adaptation look like? An example I've seen work is a tweak of the SOP, supported by a tweak of the involved IT system, tried in at least one clinic. The energy I see when these empowered cross-functional teams get together is nothing by magical. It's like you unleash the power of people, removing the shackles of bureaucratic siloed processes by which they were bound. The magic is followed by success. [At one client who followed this approach](/blog/bringing-business-clinical-operations-and-it-together-to-deliver-faster-better-business-outcomes-at-spectrum-healthcare), we saw breakthroughs in business consolidation initiatives, digital enablement, and rolling out telemedicine at breakneck speed - without missing a beat. So - Spend some time Identifying the right Product topology/architecture for your organization. This is key to creating an environment where leaders can empower people to go figure out how to move the needle on a customer experience. Then, help these product-oriented teams slice their work in a way that enables them to iterate. The example above talks about healthcare providers. What's the Product architecture in your world?

Simplifying Scaling Through Fractals, Snowflakes and Turtles

Yuval Yeret — Fri, 11 Oct 2024 00:00:00 GMT

Can you dance at all parties? Be the expert at the intersection? Sounds like an oxymoron—Jack of all trades, master of none. Beyond the fact that you need to be curious, open-minded, and a lifelong learner, I have a trick for you. You don't need to be an expert in every snowflake when you're a snow expert. Once you understand the pattern of a Fractal, you can zoom in and out. Focusing on the underlying principles of the practices/frameworks you're using will make grasping new ones much easier. Pattern-matching will help you see the similarities and you will be able to focus your learning effort on the differences. You can then consider whether the new patterns can be useful in other contexts. Here are some examples of how I've done this: I've seen the similarities between OKRs, EBM, and Agile ways of working to help me get up to speed on OKRs much faster, but also to improve OKRs with emphasis on Agile and Evidence-informed thinking. I've helped leaders see that flow is a useful lens at all levels and that Kanban can help see and improve flow for individuals, teams, groups, portfolios and the enterprise. I've helped portfolio leaders move from push/tell/centralized control planning in strategy deployment (OKRs) to decentralized control with alignment through [patterns used in PI Planning](https://safesummit.com/2024washingtondc/full-agenda/). Once you start to see Snowflakes and Fractals, I promise you'll start to see them all the time... Curious about Turtles? It's [Turtles All The Way Down!](https://en.wikipedia.org/wiki/Turtles_all_the_way_down)

Leveraging Agility on a Ways of Working Simplification Initiative

Yuval Yeret — Fri, 11 Oct 2024 00:00:00 GMT

FlowImpact Yoga, a fast-growing network of studios, continues using the Think It, Build It, Ship It, Tweak It operating system. On the last employee survey, they saw improvements in cross-company collaboration and goal clarity, which makes the mediocre results in Decision-Making an area to try to improve. In a leadership team meeting, they decided to treat this as an OMTM (One Metric That Matters) and treat it as a worthy goal. Early on, they realized this was a multi-pronged issue with many moving parts and no clear-cut solution—a Gordian knot. It was an excellent opportunity to leverage agility practices to tackle the complexity. As the cross-functional team that opted in to tackle this gets going, a key question they ask themselves is, "What will be our Increment? How will we achieve transparency that gives us the evidence we need for steering?" They quickly realize that moving the needle on the metric that matters will be a lagging indicator that wouldn't move fast enough to steer. However, they can ask their colleagues to rate Decision-Making Speed and Autonomy for each major decision being made as well as on a more frequent basis, e.g., every two weeks. They believe this will be a good leading indicator for the metric that matters. The desire to get traction on the leading indicator leads them to break the challenge into small slices and focus their discovery, validation and intervention. They select one decision type in one area as an initial area for their experimentation. This is when they move from Thinking to Building. In this case, building means trying out new decision frameworks and decentralizing several decision types while providing improved context for alignment. By finding a fast-moving outcome metric, they can try many more things in the same period. That proves crucial because their first experiments fall flat. But after several tries, they find an intervention that shows promise. They spend a bit more time validating and then start working towards a wider deployment of this intervention—they are getting ready to "Ship It" into the organization. Once the intervention is in place, they continue to monitor, find some issues in other decision areas where the alignment approach requires a different structure, "Tweak" the decision-making SOP a bit, and then they are happy with the results they're seeing. Decision-making is no longer the biggest constraint people face. It is time to move on to the next one. So... ## What is your biggest organizational constraint right now? The One Internal Metric That Matters? What's a leading indicator you could focus on when trying to move the needle? What would iterating towards improvement look like?

Iterating Beyond Software - Applying Agile/Evidence-Based Management in Consumer Goods, Food & Beverage, Pharma/BioTech and Beyond

Yuval Yeret — Thu, 10 Oct 2024 00:00:00 GMT

Working Software. Done Increments. Two related concepts in the agile world that people trying to leverage Agile/Scrum's empiricism outside of the software/technology space struggle with. The intent behind these practices is to achieve transparency to validate/invalidate assumptions — managing based on evidence. The key idea is to get transparency as early and often as possible to minimize the risk of continuing down the wrong path. ## What Is the Non-Software Equivalent of 'Working Software'? The assumptions we want to derisk could be in areas such as: - **Desirability** — will they want it? - **Viability** — can we make money on it? - **Feasibility** — can we do this, can we make this? - **Sustainability** — can we do it in a way that is sustainable for our people, society, and world? We face these assumptions whether we're building a fully digital product, a cyber-physical system, consumer goods (laundry care, grooming, beverages, food), or tackling a complex challenge — such as how to get from initial indication to FDA approval as quickly as possible while navigating unknown competitive threats, clinical trial results, and regulatory environment. The need for transparency and derisking is universal. Accommodating "transparency every couple of weeks" is the non-trivial challenge. ## How Do Done Increments Work in Consumer Goods? Some environments make working increments easier than others. **Food and beverage formulations** — tweaking a formula is relatively fast. If you have a good setup for consumer testing, you can get increments in front of customers quickly. A "Test Kitchen" approach—a rapid-iteration lab environment—is an excellent example of this model working in practice. It operationalizes the 'Done Increment' concept for physical products, enabling inspect-and-adapt cycles on a cadence comparable to software sprints. **Razor design** — physical products can sometimes be tested with 3D-printed parts. This is a compromise in fidelity, but the earlier feedback is worth the tradeoff. The key question is always: is this increment good enough to generate the feedback we need? **Gating mechanisms as increment checkpoints** — most consumer goods companies have gating mechanisms before commercialization (desirability, viability, feasibility). You can use these as structured increment review moments, but make them more frequent and lower-fidelity. Rather than waiting for the full gate, run a lightweight multi-criteria review every few weeks. ## How Do You Apply Agile Empiricism in Pharma and Biotech? The FDA approval process is a good stress test for agile empiricism beyond software. Suggesting "put your submission package in front of the FDA every two weeks" is unrealistic. But the principle—frequent inspection of assumptions—still applies. In long-cycle domains like pharma R&D, you break the path into shorter hypothesis-testing loops. A clinical trial cannot be shortened, but the work of preparing, designing, and de-risking it can be managed iteratively. **Mock regulatory panels** — a panel of experts convened every few weeks to review where you stand. Not a complete submission, but a holistic review of one risky aspect. The purpose is to find the smallest experiment that gives you meaningful evidence about your biggest assumption. **Clinical hypothesis tracking** — breaking the path to approval into explicit hypotheses (safety, efficacy, competitive differentiation) and maintaining visible tracking of evidence. This is Evidence-Based Management (EBM) applied to R&D. EBM provides a structured way to track whether the organization is improving its ability to deliver value—regardless of whether the output is code or clinical outcomes. **Discovery-to-validation cadence** — moving from Build It to Ship It is a considerable cliff in regulated development. Iterative work happens in the Think It and Build It stages, building up enough evidence to clear that cliff confidently. ## What Is the Core Principle for Iterating Beyond Software? There's no single answer—but there is a single principle: **look at the tradeoff between delayed feedback, the risk of inaccurate feedback due to increment fidelity, and the cost of creating each increment**. - Delayed feedback = higher risk of discovering problems late - Low fidelity feedback = risk of learning the wrong lesson - High cost of increments = pressure to batch into fewer, larger iterations The right balance is context-specific. In formula development, cost is low and fidelity is high—so iterate fast. In razor manufacturing, full mold cost is high—so use 3D prints, accept lower fidelity, and iterate early before committing to tooling. We want early and frequent transparency that enables us to steer using evidence. Practices like Scrum's Definition of Done serve that intent—adapted to fit the context, not applied mechanically. The core value of Scrum—empiricism through frequent inspection of working increments—applies in any domain with uncertainty. ## What Agile Practices Translate Best Outside Software? **Practices that translate directly:** - Sprint cadence for regular stakeholder review - Retrospectives — inspect and adapt the process, not just the product - Product Goal and Product Backlog — a prioritized list organized around outcomes - WIP limits — preventing too many parallel experiments from diluting focus **Practices that need adaptation:** - Daily Scrum — still useful, but may be weekly in slower-moving R&D environments - Definition of Done — requires careful design per domain (e.g., a tested formulation, a 3D-printed prototype) - Sprint Review — the "shippable increment" becomes the appropriate fidelity increment for that domain **Practices to be cautious with:** - Story points and velocity — often misleading; prefer flow metrics - Burn-down charts — useful if work is genuinely decomposable; often not the case in R&D --- _Working on applying agility in a non-software domain? [Explore agility beyond software advisory](/agility-beyond-software) to discuss your context._

Why The Intersection Matters (A Case Study)

Yuval Yeret — Tue, 08 Oct 2024 00:00:00 GMT

I encounter more and more people struggling to find a clear path in the agile space. They are dealing with a complex, scaled environment with many legacies, with some scaling patterns needed. SAFe resonates to them as an approach that fits their organization's appetite (or lack thereof) for change/risk but they also want to make sure that the agile heart is still beating in there. They find someone at the intersection of SAFe and the Professional Scrum and Kanban world to be a safer bet (sorry, had to). Experts at the intersection keep you honest. They challenge you to think about where you're going. They have options. They also make for better training, more profound coaching conversations, more buy-in, better understanding, and therefore, smoother and more effective change - leading to faster outcomes of your transformation. When they realize that their impediment is alignment, integration, and flow across multiple products and some of the organizational operating model assumptions and want to introduce agility at the portfolio level, they appreciate someone who was also involved in some of the most enormous scale Kanban case studies AND knows their way around Evidence-based Management and OKRs to be helpful. Anybody can talk about SMART goals. Fewer experts can leverage the intersection to think of applying INVEST for your Goals/OKRs, applying Evidence-based Management to them, not to say to think of applying Flow/Kanban to your OKRs. When they decide to take agility out of the technology organization to marketing, sales, and eventually to the whole company, they appreciate someone's broader perspective that leads to seeing and emphasizing patterns and principles rather than practices and methodologies because they've tried to apply mechanics before and ended up with Agile Theater. With the expert at the intersection, they deliver a cross-functional initiative with no actual software in it ahead of time, with outsized market value unlocked due to the resulting agility (even though they might not be using all the agile practices). ## Not everyone appreciates the value of the intersection. Optionality seems to complicate things. Maintaining expertise in different areas isn't trivial.

Product Thinking for Product Leaders: How to Apply It to Your Organization

Yuval Yeret — Mon, 07 Oct 2024 00:00:00 GMT

"_PMs work on the 𝗽𝗿𝗼𝗱𝘂𝗰𝘁. Product leaders work on the 𝗽𝗿𝗼𝗱𝘂𝗰𝘁 𝗼𝗿𝗴._" - Ed Biden Let's take it one step further. Product Leaders should work on the Product Organization using a Product Approach. Successful Product Leaders I worked with applied their Product chops to working on their Org. They Hypothesize, Experiment, Keep options open, Inspect and Adapt, Orient to Outcomes, and use Evidence to guide them. https://youtu.be/bVBYTzc47Co They DON'T spend 100 days planning the reorg to solve all Product organization problems. They get going with bite-sized changes within 10 days. (If we were playing buzzword bingo, you could call this Bias for Action I guess) They apply a Product Operating Model to introduce a Product Operating Model. They consider themselves stewards of the Product Management experience and frame their goals and actions around serving their customers (The PMs and other stakeholders of the Product organization). They treat their potential changes/interventions as a hypothesis and walk the truth curve. They use Minimum Viable Changes. They engage and empower cross-functional teams of the right people (often bringing in perspectives outside the Product Org) to figure out complex problems. You might consider this Product Operations. Initially its a capability the Product Leader and core Product Management team might focus on. Over time, As their organization scales it often makes sense to organize a specialized enabling / platform team to help steward the Product Operating Model. The most successful ones? They rally their colleagues to [work on the whole company as a product](/blog/the-next-agile-frontier-agile-company-development).

The Intersection

Yuval Yeret — Sun, 06 Oct 2024 00:00:00 GMT

SAFe, Scrum, Kanban, Spotify Model Empiricism, Flow Revolution, Evolution Agile for Software Development, Agile Beyond Software, Developing your Company using Agile Running Lean, OKRs, EBM, EOS, Scaling Up, Decision Strategies, D4X, The Advantage, Liberating Structures Incubators, Accelerators, Pre-seed Startups, Scaleups, Small/Medium Businesses, Fortune 50 BioTech, Pharma, Technology, FinTech, CyberSecurity Agile Transformation, Product Operating Models Process, Practices, Principles, Culture Founder, Teacher/Trainer, Coach, Mentor, Consultant, Advisor, Speaker, Writer, Developer, Leader, Facilitator Individual, Team, ART, Portfolio, Company Operating Systems, Networking Design, Principles of Product Development Flow, Operating Systems for Ways of Working SAFe Fellow, SPCT, Scrum.org PST, Kanban Trainer, Professional Scrum with Kanban Guide and Workshop Co-Creator I always found myself at the intersection of many ideas, contexts, and communities. This creates exciting opportunities to cross-pollinate, co-create, and innovate across domains. It also creates a challenge - what am I? Why should people work with me? I think I get it now. I'm at the intersection, helping bridge / integrate different ideas. I write, speak, teach, coach, and mentor people who care more about outcomes than a specific path. They are trying to navigate this complex landscape of ideas populated with many people who are comfortable in their own neighborhood/community and try to build walls around it. This approach isn't for everyone. It's simpler to stick to a specific path and follow it. My people care more about connecting paths to shape new ones. I'm glad you're here. PS WDYT about "The Agile Intersection" as an idea for a podcast? If you like it and want me to get going, reply with INTERSECTION. I'm thinking about it. Any evidence that there's interest/demand might help me prioritize it.

Hacking your way to an Evidence-Informed Mindset

Yuval Yeret — Fri, 04 Oct 2024 00:00:00 GMT

Evidence-Informed - Making decisions informed by evidence. This includes decisions such as: - Prioritize - Go/no-go - Continue / Stop / Pivot Opinions, Convictions, Lack of Trust, Power dynamics, and Impatience make it hard to introduce evidence-informed thinking into an organization's day-to-day decisions, whether at the level of a Product Manager/Owner, Portfolio Leader, or the C-suite. Over the years, I've collected a few cultural hacks to make this mindset shift a bit easier: - Minimize the use of the term "Requirements" (which implicitly and subconsciously infers that something is required). I prefer the language of Options, Bets, or, if that's too hardcore initially, Items. - Identify a set of attributes to consider (e.g., direct value, future opportunity, strategic alignment) as part of the decision - at a minimum, this helps flush out the rationale behind an opinion and helps everybody align - Explicitly include a "Learn / Reflect" stage as part of the life cycle—and make sure everyone knows it's there and that it actually takes place. This both drives learning and improves future decisions but also associates some accountability with the conviction to "go do it." - Agree on a clear definition of what a "Home Run Success" looks like - in outcome/impact-oriented language ("this moved the needle this way" vs. "we built this, and it is working") - BEFORE committing. - Agree on outcome-oriented leading indicators that signal we are heading towards success. - Agree on a clear definition of what a "Fast Failure" looks like - what would be a leading indicator that we are going nowhere and need to stop/pivot. (Annie Duke calls this ["Kill Criteria"](https://www.linkedin.com/posts/lennyrachitsky_one-of-annie-dukes-top-tips-for-making-better-activity-7192194217660616705-tCMM?utm_source=share&utm_medium=member_desktop)) - Identify a bright spot—an example of evidence-informed behavior that was used to unlock business value or avoid significant failure/waste. - Gamify it. For example, one business group I work with decided to start a "Shark Tank" process. This is also another hack: If you can get people to come up with their own ways of introducing evidence-informed behavior, embrace and amplify those even if they're not exactly prescribed in your process. Finally, It's not a hack per se but choose your battles. Live to fight another day. It might be too late to introduce evidence-informed thinking to an initiative already in flight. In my experience, evolution often works better than revolution for this shift. ## Now that I think of it, evolution often works better than revolution for most shifts.

How do you fix OKRs that have lost the plot?

Yuval Yeret — Wed, 02 Oct 2024 00:00:00 GMT

In this video, I explore the core issues many organizations face with their OKR (Objectives and Key Results) practices. We’ll revisit the fundamental principles that often get lost in the process of setting and tracking OKRs and explore how to fix misaligned strategies. Tune in for actionable insights to help you reset your approach, align your OKRs with meaningful business outcomes, and foster a culture of focus, learning, and growth. 🚀 **Key Topics**: - The core principles behind OKRs - Common pitfalls and how to avoid them - Aligning OKRs with real business impact - Practical steps to reset your OKR approach 🔗 Read the full article: [Fix Your OKRs: Back to First Principles](/blog/fix-your-okrs-back-to-first-principles) https://youtu.be/W6gTu2iC2AE

Think It Build It Ship It Tweak It - a Business Fable

Yuval Yeret — Wed, 02 Oct 2024 00:00:00 GMT

FlowImpact Yoga is a rising power in the fitness industry. A PE firm has just purchased it, and its leadership is hard at work, making the best of the holding period to grow and improve the business. There are many ideas on the table. The leadership team realized that 1. They need to focus, and 2. Many of these ideas are business bets they would do well to validate/learn from. Jim, the CPO, recalls a mode he read about once in an article about [how Spotify Builds Products](https://blog.crisp.se/wp-content/uploads/2013/01/HowSpotifyBuildsProducts.pdf). It talks about “Think it, Build it, Ship it, and Tweak it." He suggests to the COO, Ella, that they use it to start managing their business initiative portfolio. This model works for any business initiative portfolio, not just software product teams, as long as leaders can define hypotheses and explicit signals. They set up a high-level Kanban board in their management tool, plugging in all of the inflight initiatives and categorizing them according to their current state. There’s too much in the “Build It” category, which is worrying but unsurprising. They decide to stop starting new initiatives until the queue clears up. In their leadership meetings, they walk this Kanban board right to left. Ella suggested this based on her experience in Lean. Walking the board right to left forces learning-first decisions and reduces the temptation to keep starting new initiatives. They start from ideas in **“Tweak It”** to see if they’re ready to move on to “business as usual.” Have we achieved our outcome hypothesis? What can we learn from the metrics? Are we still moving the needle, or are we seeing diminishing returns? Is this still the business constraint? The new shorter midday class schedule aimed at the WFH crowd seems to be proven and well-tuned and ready to become part of SOP. Then, they talk about business initiatives in the process of **“Ship It**.” The heated yoga studios are being deployed throughout studios in the Midwest. Ella asked the leader for this initiative some questions about the learning curve of deploying the heated studios and whether the classes in ready studios are filling up according to expectations. They are acting like a mini-founder—excited about this bet, learning and adjusting along the way. They then discuss the initiatives in **“Build It.”** They discuss outcome-oriented leading indicators from the “concierge” experiment in the Boston studio. Enough evidence warrants “Shipping” this service across the network. Jim is worried that the “inactivity-based churn call from the studio head” feature doesn’t seem like its moving the needle. Because churn is a crucial metric they ask the team to continue to experiment. The biggest mistake at this stage is treating the categories as labels rather than decision gates. Each stage should include evidence checks and capacity discipline. Then they get to the bets in “**Think it**.” They look at the initiative to run a Yoga for Winter Sports class. What is the insight? What is the satisfaction gap this idea is aiming at? Ella, Jim and the rest of the leadership team review the body of evidence and decide that while the idea is interesting, there’s too much going on right now. Every month, the leadership team gets together and reviews their portfolio of business bets. Some of these are digital-heavy. Some have no digital aspect in sight. That doesn’t matter—because they are all business bets that benefit from outcome-oriented, evidence-informed decision making. Ella and Jim are invited to the PE firm Portco Summit to present how they’ve applied a Product Operating Model to the business. While fewer business initiatives are in motion, more initiatives impact the metrics that matter, and the business has improved traction overall. Dare we say there’s more **Flow** and more **Impact**? --- _If you want to apply this operating rhythm in a real portfolio context, explore [Portfolio Agility Advisory](/work-with-me/portfolio-agility/) or [Strategic Alignment with OKRs](/work-with-me/strategic-alignment-and-execution-at-scale-leveraging-okrs/)._

Tackling Projects in a Product Operating Model World - Aka Herding Wildcats Down Waterfalls

Yuval Yeret — Mon, 30 Sep 2024 00:00:00 GMT

Projects and initiatives are second-grade citizens in a [Product Operating Model](https://www.scrum.org/resources/moving-agile-product-operating-model-evidence-based-approach-delivering-products-digital-age) world. The organization worked hard to organize around products, creating empowered product teams, each with its product manager/owner focused on a product goal that hopefully aligns with the organization's larger strategy. At scale, you might have Product Groups and even Product Portfolios, each empowered to drive outcomes in their area. This is great because it localizes dependencies and makes collaboration easier between the different people involved in the product. But what do we do when a "strategic cross-product project" shows up in our funnel, or more importantly, when we decide to explore/deliver it? One of the behaviors I've seen repeatedly in organizations following a Product Operating Model is that while each Product operates in an iterative agile fashion, the integration across them looks more akin to the traditional big batch waterfall. I've seen people interpret the Product Operating Model as a divide-and-conquer mechanism, which can work when focusing on individual Product Goals but can lead to disaster when tackling integrative work. There are several approaches to tackling these cross-product initiatives/projects in a Product Operating Model world, which I will explore in a future article. For now, my suggestion to you is to make sure that you're applying the first principles of agility to these cross-product initiatives/projects/programs as well: - **Avoid prioritization hell**—Use a mix of strategic goals that cut across the portfolio of products, as well as a clear portfolio backlog and ownership, to provide clear guidance to the different products regarding the balance/priority of cross-product initiatives related to the individual products. - **Avoid integration hell** - Maintain transparency based on integrated working products/solutions on an ongoing basis - which will mean slicing the cross-product initiative into small cross-product slices. - **Avoid getting surprised** - Frequently Inspect and adapt based on transparency and feedback. - **Organize around value** - Think of ways to facilitate effective collaboration among the people involved in the work. Remember that stable Product Teams are an optimization designed for a certain context—there are situations where it might not be optimal. - **Discretionary approaches—you don't have to deal with all cross-product initiatives using the same approach. Have a set of heuristics (e.g.,** complexity, coupling) for when to use more collaborative patterns. - **Inspect and adapt the model itself**. If it's not helping you drive strategic work, it's time to tweak it. The model should be working for you, not you for it. Having said that - optimize for the whole, not for individual parts (Products in this case) - **Outcome-oriented Goals, Evidence-informed -** Ultimately - Don't let the fact that we are calling this a project or initiative take away from the value of treating it like a Product - with an outcome-oriented goal, and continuous adjustment based on evidence (from inspecting working integrated increments as frequently as makes sense). The bottom line is to keep your thinking hat on! Reflect on why you're using a Product Operating Model and its underlying principles, and apply principles and patterns in context rather than copying practices. One of the interesting questions I didn't cover today is what are the accountabilities involved in such a cross-product initiative/project (especially who should be leading). I'll talk about that some other time. In the meantime, maybe you can already see what might make sense if we look at it from the first principles of agility and leverage agility patterns. ## https://youtu.be/rCCdu7bzhAc _Designing and evolving a product operating model is one of the highest-leverage things a product leader can do. [Explore Product Operating Model advisory](/work-with-me/figure-out-your-product-operating-model-strategy) or [let's talk](/work-with-me)._

Company as a Product

Yuval Yeret — Thu, 26 Sep 2024 00:00:00 GMT

_"One of the things that we do differently is that we treat our company as a product"_ — Jason Fried, CEO and co-founder of 37signals ([Wisdom From The Top with Guy Raz](https://open.spotify.com/episode/75h6Fnu6RoNJYhjLsGKGwv?si=7bd2bfe310b742d7)) _"Culture is a Product. Every company builds two products — one is the product they build for their customers, and the other is a product they build for their team."_ — [Dharmesh Shah](https://www.linkedin.com/in/dharmesh/), Founder and CTO at HubSpot Some of the most successful founders have already unlocked a secret that most organizations miss entirely: the organization itself is a product — and it deserves the same rigor, investment, and continuous improvement as anything you ship to customers. ## What Does It Mean to Treat Your Company as a Product? Treating the company as a product means applying the same disciplines that make great product teams effective — customer discovery, iterative delivery, outcome orientation, and continuous improvement — to the development of the organization itself. Through the lens of a Product Operating Model, this breaks into three dimensions: **Mindset** — Approach every organizational challenge with a view to stakeholders, users, outcomes, dependencies, ownership, and value. Ask "who are the customers of this internal process or experience?" before asking "what should we build?" One concrete example: seeing yourself as a Steward of the employee experience. One of Yuval's clients — a COO in everything but title — chose the title "Head of Stewardship" to make this mindset explicit and visible to the organization. **Alignment** — Organize, structure, and manage to a product model. Define cross-functional teams around company-as-a-product challenges. Align them to shared outcome-oriented goals (OKRs, for example). For instance: who needs to be involved to improve the hiring and onboarding experience? One organization carved out a small cross-functional team involving People, IT, and hiring managers (as customers of this product) to collaborate on the whole experience — working as a team aligned to a shared OKR. **Investment** — Plan and invest in your company like it is one of the products in your portfolio. Define a strategy for it. Set intermediate goals. Make conscious investment choices between improving the company vs. building customer-facing products. Manage the flow of those investments. ## Why Is the Company-as-a-Product Idea Important? Most organizations invest heavily in developing products for customers and almost nothing in deliberately developing themselves as organizations. The result is that the management operating system — how decisions are made, how teams are structured, how work flows, how strategy is executed — becomes increasingly misaligned with the complexity of the work. The company-as-a-product idea closes this gap by applying the same rigor to internal development that ambitious product organizations apply to their customer-facing products. The practical implications are significant: - **Internal customers** — employees, teams, and leaders are customers of internal products (HR processes, tooling, communication systems, reporting). Treating them as customers changes how you design and improve these systems. - **Outcomes over outputs** — rather than measuring "we held 200 onboarding sessions," you measure "new joiners reach full productivity 30% faster." The outcome frame changes what gets prioritized. - **Continuous improvement** — rather than running an annual reorganization or a once-a-decade ERP replacement, you improve the organization iteratively, with frequent inspection and adaptation. - **Explicit investment** — rather than letting the organization drift, you make deliberate portfolio decisions about where to invest in organizational capability vs. customer-facing product capability. ## What Does the Agile Product Operating Model Add to Company as a Product? The agile and Product Operating Model layer makes "company as a product" actionable rather than a metaphor: **Designing self-managed, empowered teams** with minimal dependencies — applying the same team topology thinking to internal teams (People, Finance, IT, Legal) as to product teams. **Working in quick iterative cycles** — building increments of organizational value, testing them with internal customers, inspecting results, and adapting. The equivalent of "working software" for internal products is a meaningfully improved employee or team experience. **Aligning to outcome-oriented goals** — OKRs or similar goal systems applied to organizational improvement work, with leading indicators to track whether the change is actually working. **Focusing on the right things** — stop starting, start finishing. Even organizational improvement work can become a portfolio of too many simultaneous initiatives, each competing for the same leadership attention. **Leveraging proven frameworks** — Scrum, Kanban, and SAFe practices that work for product development translate well to managing complex organizational change when applied with appropriate adaptation. ## What Are Practical Examples of Company as a Product? **Developer Experience as a Product** — a team explicitly responsible for the tooling, build systems, testing infrastructure, and developer workflows that make the engineering organization faster and less frustrated. This team has a Product Owner, a roadmap driven by developer satisfaction and productivity metrics, and a regular cadence of shipping improvements. **Employee Onboarding as a Product** — instead of an onboarding "program" run by HR, a cross-functional team continuously improves the new joiner experience: measuring time-to-productivity, testing different onboarding structures, and treating new joiners as customers whose journey needs to be designed and optimized. **Hiring Process as a Product** — applying product discovery to recruiting: interviewing candidates (as customers of the process), hiring managers, and successful hires about where the hiring funnel creates friction, then iterating on the process. **Internal Knowledge Systems as a Product** — wikis, documentation, and knowledge management systems treated as products with users, metrics (is the information people need actually findable?), and a team accountable for their quality. ## Who Should Be Thinking About Company as a Product? The company-as-a-product mindset applies across leadership levels: - **Team leads and managers** can apply it to the team experience they are creating for their reports — the psychological safety, clarity of direction, quality of feedback, and fairness of process. - **Functional leaders** (People, Finance, Legal, IT) can apply it to the internal services and experiences their functions deliver to the broader organization. - **COOs and Chief of Staff leaders** can apply it to the company's operating system — how decisions are made, how information flows, how resources are allocated. - **CEOs and founders** like Jason Fried and Dharmesh Shah can apply it to the organizational design and culture they are actively building, rather than passively experiencing. At every level, the shift is the same: from managing the organization as an inherited system to actively developing it as a product. ### Summary: Making "Company as a Product" Actionable - **Origins and Influence:** Notable founders like Jason Fried (37signals) and Dharmesh Shah (HubSpot) have long championed this approach. It aligns with modern disciplines like Team Topologies, Developer Experience (DevEx), and Platform Engineering. - **Connection to the Product Operating Model:** While the Product Operating Model defines how you deliver value to customers, "Company as a Product" is that same model turned inward. It’s about applying empowered teams and outcome orientation to your own internal structures. - **Operationalizing Culture:** Unlike traditional "culture work" which can feel abstract, this approach is operational. It defines specific internal products, assigns cross-functional accountability, and iterates based on evidence and measurable outcomes. - **How to Begin:** Identify one high-friction internal experience—onboarding, hiring, or meeting culture—and treat it as a product. Define the internal customers, set a 90-day measurable goal, and run a focused "product sprint" to improve it. --- _Interested in applying product thinking to organizational development? [Explore the Company as a Product approach](/work-with-me) or [connect with Yuval](/contact) to discuss how this applies to your context._

Transformation Blues - Fighting the nice-to-have cave of pain with Must Have and Case Studies

Yuval Yeret — Mon, 23 Sep 2024 00:00:00 GMT

My clients are often frustrated that their transformation isn't taking off despite promising results (e.g., outsized outcomes and speed by leveraging agile ways of working in a strategic initiative). One path that leaders often take is to follow initial promising results with a mandate to follow new ways of working throughout the organization. This is the classic playbook, and many consultants are happy to oblige (there’s lots of money in training and coaching large swaths of the organization quickly, where it's clear the organization cannot tackle this on its own). This brute force approach can work in some environments but more often stalls. I talked quite a bit about this a decade ago. I suggested considering the transformation landscape as a market and applying crossing-the-chasm principles and techniques - recognizing early adopters, the chasm, the need for a full kit product, etc. One concrete approach I started using and formalizing was an invitations-based approach to change (see this [guidance article](https://scaledagileframework.com/invitation-based-safe-implementation/) for an example of how to apply this in the scaled agile world) Over the years, I’ve helped leaders implement this approach, and it has created more sustainable transformation, but it's far from perfect. One frustration is that if you don’t mandate, people don’t change. I’ve always talked about the need to market and nudge, connecting the potential benefits/outcomes to the needs of the organization, but there was still a missing piece. Rob Snyder has some [brilliant content on](https://howtogrow.substack.com/p/nice-to-have-vs-need-to-have-4b9) [Product-Market Fit](https://howtogrow.substack.com/p/nice-to-have-vs-need-to-have-4b9) (Paul Stansik at ParkerGale Capital recently interviewed [Rob](https://pefuncast.libsyn.com/product-market-fit-with-rob-snyder) on the Private Equity Funcast). One of the key insights is that demand is actually your product being THE way to address THE top priority on the customer/buyer's to-do list. It needs to be a [must-have](https://howtogrow.substack.com/p/nice-to-have-vs-need-to-have-4b9) in their specific context/situation, or there won't be strong demand (and you cannot create demand, but you can meet demand). If we apply this notion to the transformation demand context, the insight is that as long as the transformation you’re trying to “market/sell” internally is nice to have, you’re not going to have much success. You will be stuck in the “pain cave,” struggling to convince people to transform and tempted to use brute force. So … To follow Rob’s advice, find the case studies inside the organization where the transformation addressed a must-have to-do list item. Use these case studies to sell/market the transformation and look for similar opportunities where it could potentially be a must-have. Pay close attention to what’s on the enterprise “to do” list. Whether it is product initiatives or business transformation and look for those with high complexity and cross-functional integration where you can show, based on past case studies, that your approach is THE way to get this complex critical thing done. It might take more time than brute force, but after a couple of home runs on critical opportunities, your constraint will be keeping up with demand… Yours Yuval ## PS I’m using Rob’s approach for this new product/service I’m working on. If you can guess which recent article was inspired by his approach, I’ll [schedule a clarity call]({{DISCOVERY_URL}}) to discuss applying this approach to get your transformation out of the cave pain. _Moving from agile theater to real business agility takes more than a framework. [Explore Business Agility advisory](/work-with-me) or [let's talk](/work-with-me)._

Situational Leadership: Balancing Involvement and Ownership

Yuval Yeret — Thu, 19 Sep 2024 00:00:00 GMT

Meet Fanny. Fanny is the founder of a successful startup. Fanny comes from a product background She starts to feel overwhelmed. She wants to stay involved but understands that even a superwoman like her has limits. While researching how other leaders are tackling this, someone on the VC Portco Slack channel she's on shared an [HBR article about an approach leaders at Apple are using](https://hbr.org/2020/11/how-apple-is-organized-for-innovation). She gathers her leadership team, and they examine everything going on right now. She asks the team to help her figure out how to show up most effectively. Fanny wants to balance being involved in the right things with being involved the right way. Fanny and the team identify four categories: - Areas of crucial strategic importance and/or high uncertainty/volatility - where Fanny is an expert. They decide that Fanny will play an Owner for these areas, but also that it doesn't make sense to have more than one, maybe two such areas in flight at any point in time. They identify their current exploration of SMB through PLG as the area Fanny will **Own**. - There are areas where Fanny is an expert, but they are quite stable, or the development/growth work is not as complex/strategic. In these areas, Fanny would engage as a **Coach/Teacher**, and someone else would be the Owner. They decided that Fanny would coach/teach Bill, a Product Manager, who would own driving and delivering their enterprise product's summer release and overall roadmap. - These are areas where Fanny isn't an expert and are pretty stable. Fanny will **Delegate** initiatives in these areas to the appropriate leader, who will act as a mini-CEO/Owner for that area/initiative. They decide to approach both the work to introduce a new Financial management system and the introduction of MEDDIC in Sales to the CFO and CRO, respectively. - Finally, there are areas that are outside of Fanny's comfort zone but are crucial and volatile, for which Fanny will need to take the time to **Learn**. You guessed it—their foray into AI and how it might disrupt their product/market is one such area. The team finds this taxonomy clarifying and liberating. It makes the situational leadership choices that they need to make as a team visual and explicit. They also realize that across all of these areas, it will help them all engage at the appropriate altitude to ensure the work happens across functions in an integrative, iterative fashion and Bets are being validated/invalidated using small increments—whether those are new product developments or new business processes/approaches. This [way of working](/blog/the-next-agile-frontier-agile-company-development) will help them identify areas where they need to adjust their leadership involvement mode and provide steering guidance without meddling. They agree that this "minimum viable change" is worth trying to see how it goes. Like other company bets, they will review and reflect on how it's going frequently and tweak/adapt/rethink as needed. They also understand that a lot is going on and they suspect that while situational/discretionary leadership might help, it might not be enough. They decide to reflect on that in their next leadership strategic session. Fanny has seen a "[Bets Kanban](https://www.youtube.com/watch?v=_SjSg565pqk)" that one of her buddy CEOs started using to drive conversations about flow and focus at the company level, which she wants to show and discuss with the team. ## PS Friends protect friends from unsustainable leadership situations. Would you please take a minute to think about who else should see this article and share it with them? _Running your company as a product — with evidence, iteration, and clear accountability — is how modern high-performing organizations operate. [Explore Company as a Product advisory](/work-with-me) or [let's talk](/work-with-me)._

Lazy engineers leverage the Product Operating Model

Yuval Yeret — Wed, 18 Sep 2024 00:00:00 GMT

**"We are a team providing services, why should we care about this new Product Operating Model?"** Meet Yuval. Yuval is an engineer on the IT networking team. They are a shared services team responsible for the organization's networks as well as helping application teams in his organization get their applications working in production. It is 1995, PowerBuilder UI over SQL\*Net accessing an Oracle Database is all the rage. (And the term DevNetOps is decades in the future, but already being practiced... but let's talk about that another day...) Yuval and his colleagues are lazy\*. While they enjoy driving to a remote branch once in a while to help an application team deploy and stabilize their new application, it's become a bit repetitive to go out there and see that the new application isn't really tuned for the slow networks between the branch and HQ. \*\_I’m lazy. But it’s the lazy people who invented the wheel and the bicycle because they didn’t like walking or carrying things.(\_Polish Nobel Peace Prize winner [Lech Wałęsa](https://en.wikipedia.org/wiki/Lech_Wa%C5%82%C4%99sa)) Yuval and his team come up with the idea to improve the service and provide a simulated branch environment at HQ, and offer the service of testing your application in the lab before you release to production. This is great. Time passes and Idan, an even lazier colleague figures out that there might be better things to do than to offer the lab environment for these test (it's still work for the network engineering team). He comes up with a simulator that can run on the PC desktop from which the application developer is testing. Idan just made the networking engineering team a platform team that enables developers to self-serve. What is happening here? Yuval, Idan and colleagues are doing two things at the same time. They are providing an ongoing service, while they are thinking about ways to improve the service. They are thinking about the service as a product. They are constantly thinking about how to create leverage - more value to the organization (and less work and more time to play video games - that's the best test for the LAN performance...) Fast forward 30 years. Shared services teams are asking "Why is this new Agile Product Operating Model applicable to us?" If you care about improving the services you're providing and/or struggling to service demand with limited capacity, you need to think about how to productize your services. What can you automate? what can you systemize and expose as a self service? There might be many opportunities - which of them is most valuable? what would create the best outcomes for the people you are serving? Once teams start to think this way - everything in Product Thinking and in a Product Operating Model suddenly becomes useful. Agility becomes a useful way to navigate the uncertainty of which self-service capabilities will be consumed and which will be rejected. Before you conclude that shared services / operational teams need to use agile/product ways of working for all their work, note that this isn't necessarily useful, repeatable operational work. Many shared services teams focus on the flow of operational work and use agile/product techniques to manage developmental/capability improvement work. So... ## if you're providing a service, think about how and where product thinking can help you be a hero. _Designing and evolving a product operating model is one of the highest-leverage things a product leader can do. [Explore Product Operating Model advisory](/work-with-me/figure-out-your-product-operating-model-strategy) or [let's talk](/work-with-me)._

Insights from Developing The Code / Operating System For My Business

Yuval Yeret — Thu, 12 Sep 2024 00:00:00 GMT

I’ve been spending some time working on my business recently. It's time for some dogfooding and drinking my own champagne. I’m spending quite a bit of time in my [Lean Canvas](https://www.leanfoundry.com/tools/lean-canvas) (actually pondering several different ones), working on deep Ideal Client Personas (aka [Dream Clients](https://www.kurlycreative.com/blog/dream-clients-new-business), [Lighthouse Clients](https://www.linkedin.com/posts/kenyarmosh_how-i-closed-more-than-50m-in-client-services-activity-7148297588545404928-kLJs)), using my [Personal Kanban](https://www.personalkanban.com/) much more, and thinking seriously about using a CRM. I also started looking at new approaches that I haven’t leveraged before and encountered [StoryBrand](https://storybrand.com/), [Scalable Service Offers](https://theremotesolopreneur.com/), [Coach Builder](https://coachbuilder.com/), [FounderOS](https://www.founderos.com/) and others. (ChatGPT has been a good pal for this journey, by the way. We're chatting about a certain approach and using it to sharpen my take on my business. I'm trying to do that while walking in fresh air when I can.) You might have noticed I'm posting more frequently, and the emails might look slightly different (I switched to ConvertKit and am considering what role email sequences could play). You might also have noticed a different focus/style to my content. Maybe it doesn't resonate with you that much, maybe it resonates much more (I'm trying to laser focus... not sure I'm there yet...) This is all a bit of “Inside Yeret Agility,” so why would you, dear listener, care? One of my insights is that many of these approaches describe **systems** that you can use. Matt Gray even calls his approach an Operating System (FounderOS). As a business owner/founder (whether you’re a service-oriented solopreneur like me, a creator, an agency owner, or a startup/scaleup leader) **you have different systems in your business that all need to work well for the business to create value for the right customers and then capture value.** How you run this system can, of course, dramatically affect how well your business runs. As a software engineer who switched from developing/tweaking software to developing/tweaking processes and organizations, my metaphor is that each **system runs on a certain “operating system/code”** . E.g., your Sales system could be running on “ad hoc” or “[MEDDIC](https://meddicc.com/meddic-sales-qualification-and-frameworks)”. Marketing could be using content/inbound marketing. I’m **not** talking about the tools used (like Workday, Salesforce, Hubspot) but about the **structures, processes, and ways of working**. At any point in time, you could be investing time in installing or improving the “code” in any of these systems. I’ve found myself tempted to spread thin across all systems or focus on a system without evidence that it's the right place to invest. This led me back to a system of systems view - an **overall operating system that you use to manage your “development efforts.”** Every business has this system of systems. What “code” this system runs could vary from “ad-hoc,” to annual plans. If we accept systems thinking - that notion that investing in developing/tweaking/replacing the “code” in the right system is crucial to affect the overall performance of your business, it is then essential to think about what “code” needs to run for this vital system of systems. We want something that will help us see the whole - this is where value stream thinking, or thinking in pipelines/chains, and having the right metrics/telemetry is necessary. How does value flow or get stuck? Whether its the customer journey, employee journey, new product / capabilities journey, what are our constraints/bottlenecks? Where should we focus? Goldratt would urge us to always look for the constraint and focus on it. Sometimes its awareness/attention. Sometimes its conversion. Sometimes its poor delivery. Sometimes its finding talent to grow. Once you have some data/evidence you can make an informed bet to focus on improving what’s going on at a certain constraint. Getting from a decision to improve to actually improving is a different story. One obstacle is your limited capacity to work ON the business since you must also RUN the business. Another is that even if you identify a constraint in a certain area, dealing with it might require tweaking/overhauling multiple systems (e.g., churn could go back to sales selling to the wrong clients, marketing using lousy messaging, and even the wrong ideal customer profile). When you’re a solopreneur like me, I can look in the mirror and have a tough chat with myself about any of these things. As your organization grows and specializes in tackling these constraints, it becomes a cross-functional endeavor, not to mention integration hell. Integration hell. Where have we heard this term before? Hmmmm. So, what should we do to derisk this work on scaling constraints? What sort of operating system would be a good fit here? That would leverage cross-functional teams empowered to achieve an outcome, who work on small slices, integrating frequently, trying things out, and deciding whether to pivot or persevere. Software developers started to organize their work in cross-functional teams (crossing functions inside technology/IT/Product) running iterative cycles focused on working integrated software to derisk software development. Over time, we started to see departments such as Marketing use similar techniques in their function (cross-functional here means Digital/Field/Event/Social/Product Marketing/etc,). [Growth Hacking](https://en.wikipedia.org/wiki/Growth_hacking) is essentially using similar techniques to focus on growth, and here cross-functional does cut across several functions. Terms like [RevOps](https://www.salesforce.com/sales/revenue-lifecycle-management/what-is-revenue-operations/) and the rise of the CRO in the scale-up world indicate the understanding that we need to think in systems rather than focus on siloes. OKRs show promise of enabling the right behaviors but are more often than not abused and misunderstood. The next step in this evolution is to [**upgrade the operating system**](/blog/the-next-agile-frontier-agile-company-development) **for the system of systems** to give it these evidence-informed, frequent inspection and adaptation cycles run by empowered cross-functional teams capability. What’s the appropriate name for this new OS? I don’t know. I’m a developer, not a marketer… ## Anyhow, I'll get back to developing/tweaking my own systems. It's fun to be a developer again :-) _Running your company as a product — with evidence, iteration, and clear accountability — is how modern high-performing organizations operate. [Explore Company as a Product advisory](/work-with-me) or [let's talk](/work-with-me)._

‘”OKRs S&%k, but we don’t know anything better” - Scaling Founder Mode by Fixing OKRs’

Yuval Yeret — Wed, 11 Sep 2024 00:00:00 GMT

**“OKRs S&%k, but we don’t know anything better”** This was a direct quote from a cybersecurity scaleup’s Chief of Staff, but I hear the sentiment way too often from founders, chiefs of staff, COOs, and others in the scaleup ecosystem. I started encountering OKRs when working with scaleups a couple of years ago, helping leaders fix their ways of working to reap the promised benefits of “Agile.” A specific BioTech scaleup used OKRs as a “grown-up” way to manage an organization growing fast and needing more management. It felt like an **artifact of “Manager Mode” (as opposed to “[Founder Mode](https://paulgraham.com/foundermode.html)”)**. You could imagine their VC “suggesting” OKRs (and EOS). When I looked deeper into HOW they were using OKRs, I saw some familiar patterns. I’ve been helping leaders fix their Agile for a while now. It was interesting to see some of my usual nemesis patterns: 1. Using new processes to reinforce rather than bridge across silos/functions – manage dependencies rather than avoid them. 2. Calling work in different names but still being involved in the details as if it were still early days in the lab/garage/WeWork shared space – instead of providing clarity about the mission and staying at the right altitude—choosing strategically what check-in cadence and involvement is appropriate where. 3. Using cool new tools (Monday, ClickUp, Trello, JIRA, Basecamp and Kanban boards in general) but still working on too many things and inflicting context overload and unsustainable pace on everyone. 4. Telling people their goals rather than involving them in figuring out the mission and the plan. We got going [fixing their OKR](/blog/fix-your-okrs-back-to-first-principles) operating system. We started by **focusing their OKRs on the things that mattered**, not everything that was happening. We reflected on how to organize around these OKRs. We made structural changes to the organizational topology, complemented by temporary empowered teams. We **rewrote OKRs to focus on outcomes**, e.g., “Double the velocity of our search for useful therapeutics,” and brought those into a big-room collaborative goal-setting session where everyone in the company tried to figure out what this meant and what would need to be true for it to be possible (hint—it’s not about working twice as hard!). We **deemphasized mechanics and pedantic processes and emphasized principles**. This also applied to their use of agile processes. A dogmatic Scrum Guide compiler would probably have issues, but they didn’t care. They understood Empiricism (it helped that they were all smart scientists) and did what was needed to ensure they had it. That enabled them to **leverage agility (not necessarily agile!) beyond their software/technology teams**. They started using iterative, outcome-oriented, empowered cross-functional teams for initiatives such as “Scientist productivity – getting them up to speed and getting out of the way” that involved People Ops, IT, and Business Ops. **The results?** Finally, there is more **traction** towards what’s important without micromanaging. The leadership team finally has **time to focus on where to take the company**. People feel like **players, not pawns**. They are **becoming more agile** (not necessarily doing agile). They are leveraging OKRs (instead of following OKRs). They had a **scalable operating system** in place that allowed them to continue to tackle the growth/scaling milestones they would continue to face. **They found a way to [scale](/work-with-me/create-a-business-level-operating-system-leveraging-agility) Founder Mode.**

Scaling Founder Mode

Yuval Yeret — Tue, 10 Sep 2024 00:00:00 GMT

Founder Mode is all the craze these days. But here’s what I’ve seen: micromanagement doesn’t scale. Founders obsessing over ALL details? Is that the only way? What I like about Founder Mode is that it addresses head-on a problem I've been seeing for a while—the divide-and-conquer approach to scaling. The way managers are taught to run companies seems to be like modular design in the sense that you treat subtrees of the org chart as black boxes. You tell your direct reports what to do, and it's up to them to figure out how. But you don't get involved in the details of what they do. That would be micromanaging them, which is bad. (Paul Graham - Founder Mode) I agree with Paul - This modular design ignores the fact that the company is an organic, complex, system with many interactions between its parts. Trying to optimize any one piece isn't necessarily going to optimize the whole. I recall conversations with a CMO who was frustrated that her people were only thinking about their domain (Field Marketing, Digital Marketing, Product Marketing) and not integrating. “I want them to be mini-CMOs” I believe the solution isn't necessarily for founders to be involved in all the details. I think the right approach is to scale Founder Mode by selectively applying it. For each strategic company initiative, have a mini-founder who leads a cross-functional, empowered, outcome-oriented team that focuses on one metric/outcome that matters—essentially a mini-startup. For some initiatives, the Founder/CEO would be the hands-on mini-Founder. For others, they would select someone else to step up to the plate. I don't think the issue is necessarily that the professionals around the founder are fakers, but more importantly, they're hired for specialization rather than their ability to be a mini-founder. A Founder who wants to keep scaling (and still have a life!) would select/nurture leaders around him who can take on these complex cross-function initiatives instead of focusing on their turf and playing a version of the corporate "schedule chicken" game. Next, the Founder would ensure that these complex initiatives are tackled using principles used for building complex products—orienting around outcomes, iterating, learning, and adapting in short cycles. This doesn't mean the whole company needs to work this way. This approach is overhead for stable operations. A good heuristic I found when working with companies is that work ON the company is typically more complex than work IN the company. That's a good place to start applying Founder Mode. Another is to only apply it for working on the few things that really matter right now (think your REAL [OKRs](/blog/fix-your-okrs-back-to-first-principles)) [Read more about my take here](/blog/the-next-agile-frontier-agile-company-development) ## How are you scaling Founder Mode?

NEC - From Project Chaos to Predictable High-Throughput Flow

Yuval Yeret — Tue, 03 Sep 2024 00:00:00 GMT

The journey for NEC with Scrum, Kanban, and agility illustrates the effectiveness of these practices in transforming complex, real-world environments. By starting small, defining their products, having greater focus by having teams understand what their products were, and engaging leadership in transparent decision-making, NEC addressed immediate operational challenges and laid a strong foundation for sustained growth and innovation. Being pragmatic and approaching their agility journey with an agile mindset was key to enabling this sustainable, sticky change in a hectic, high-stakes operational environment. ## Check out NEC's agile journey in this recent episode of the Scrum.org Community podcast, where Scrum.org's Dave West interviews Steve Lizotte, VP of Engineering at NEC, and Yuval.

Mastering Agility Podcast - Lean Portfolio Management and OKRs with Yuval Yeret

Yuval Yeret — Tue, 18 Jun 2024 00:00:00 GMT

In this conversation, Jim, Sander, and their guest, Yuval, discuss various topics, including SAFe, lean portfolio management, and OKRs. They explore the misconceptions and polarizing nature of SAFe, the difference between a traditional PMO and a lean portfolio, and the challenges of managing different ways of working within a global organization. They also delve into the concept of OKRs, the importance of setting realistic goals, and the potential pitfalls of tying incentives to OKRs. The conversation concludes with a discussion on metrics and the value of thinking in bets. ## https://open.spotify.com/episode/5WOxtlxSZLiFhCurk3RKe6?si=VJT48FoOQAG1iHTZ2Y3fPg

Interview on the Private Equity Funcast -Understanding the Agile/Agility Ecosystem

Yuval Yeret — Wed, 29 May 2024 00:00:00 GMT

[](https://www.youtube.com/@parkergalecapital) I've been an avid listener of the [Private Equity Funcast](https://pefuncast.libsyn.com/) for a while. I find the Private/Growth Equity space fascinating—there are lots of potential synergies with my agility practice, interesting conversations, and exciting opportunities. On the Funcast, ParkerGale partners Jim, Devin, Paul, and their guests share their culture-oriented perspective and approach. True to the name, I had lots of fun discussing the Agile/Agility ecosystem, especially in the context of middle-market private equity portfolio companies with [Jim Milbery](https://www.linkedin.com/in/jmilbery/) (a Partner at the firm). I was pleasantly surprised with how much Jim knows about Agile and Agility so we could dive right into what we're both seeing in the trenches - comparing notes and ideas and riffing off each other. Some topics we covered - - The importance of principle-driven agility over rigid adherence to frameworks. - Leveraging agility in various industries, organizational functions, and broader business operations - "Agile Theater," where companies follow agile rules without understanding the process. - OKRs (Objectives and Key Results) as strategic guides rather than rigid metrics. - The unique position of private equity firms and consultants in driving agile transformations through pragmatic, principle-based solutions. I hope you enjoy this episode at least as much as I did recording it - and consider subscribing. PS For more on agility in private equity check out my article on [Agility, Evidence-based Management and their role in improving returns in the Private Equity space](/blog/agility-evidence-based-management-and-their-role-in-improving-returns-in-the-private-equity) https://open.spotify.com/episode/4HwM3O1eBY0i2oNjbi3qkw?si=14a0c7f997494305 https://www.youtube.com/watch?v=Rz54kQwAV8g

The Next Agile Frontier - Agile Company Development

Yuval Yeret — Tue, 12 Mar 2024 00:00:00 GMT

### Dealing with business growth/transformation challenges through agility I’ve been helping companies improve their operations for over a decade. A repeating pattern is where a very successful company is facing growing pains affecting its ability to scale to the next level. Some examples of the challenges I’m called in to help with: - **Losing the Ability to Innovate** You often see companies that grow successfully to the point where it seems their ability to innovate stalls. Looking deeper, you see them struggling to cope with growing technical complexity, coordination costs across teams, and leadership bottlenecks. This affects product innovation, GTM innovation, and other key business processes. - **Time to Market / Time to Learn —** The more complex the organization, the more time it takes to deliver value or close a learning loop. And in an environment of volatility, uncertainty, complexity, and ambiguity, this hurts your ability to compete. The bigger you are, the more you resemble the incumbents you once disrupted. Everywhere you look — product development or how the company runs its key business processes, there’s more and more friction and slowdown. - **Losing Key Talent —** Talented people are looking for an environment where they can thrive, have the right level of autonomy, work on interesting problems with minimum friction and headaches, and see the value and connect to a worthwhile mission/purpose. As companies grow, the way they operate becomes less and less attractive to talented people. They feel bottlenecked, stuck, and mired with more and more legacy and start looking for greener fields. ### Business/Organizational Agility — The New Business Operating System Addressing these challenges by improving our ability to innovate and deliver, solving complex problems in an environment of uncertainty, is what we call “agility.” It essentially translates to having a scalable ability to build/try/measure/learn, in fast cycles, customer-facing products, as well as business/internal processes, in a way that is aligned with the company’s strategic focus. You might also call these OKRs, Distributed Leadership, Nimble, DevOps, Lean Startup, or Scrum. While Agile was created in the IT/Software world, more and more organizations realize that its principles and thinking apply broadly. Business/Organizational Agility is emerging as the term used for this new and improved “business operating system” that applies these agile approaches across the organization, from product development/IT through revenue-generating activities such as Sales/Marketing to how the C-suite/Senior executives are working as a team on the biggest gnarliest challenges the company is facing in executing and validating its business model. This new “business operating system” typically requires some virtual reorganization to teams and teams of teams that own products/experiences/value, adoption of evidence/data-driven ways of working, and a leadership style that provides clarity and empowers teams to figure out how to work and how to achieve their goals. It includes work on focus/flow, empiricism, and continuous improvement at all levels of the organization. A useful definition of the essence of this agility is provided in the [Evidence-Based Management (EBM) framework created by Scrum.org](https://www.scrum.org/resources/evidence-based-management). This framework can also be used to assess a company’s maturity on the journey towards being an “evidence-based managed company” or operating on an “evidence-based operating system.” The EBM framework purposefully stays away from prescribing ways of working. In recent years I’ve been working with more and more companies that are applying these “Evidence-based agile operating systems” across the company. The trigger to “upgrade the operating system” is sometimes proactive internal leadership. More frequently, there’s a major event driving it. This can be a major new threat/opportunity, a major change in leadership, or an investment/recapitalization event. ### Focusing Agility Where It Matters The Most Having a company-level evidence-based operating system doesn’t mean every activity in the company should be managed in an evidence-based manner. This way of structuring/working is especially useful when working on developing — developing products, services, or generally “ [developing company](https://open.spotify.com/episode/36GowhjKkJXW0pj6Eohi0h?si=VmGTlaH2REig77ykYq7Rsw) **#2”** (the company you want to become). Running ongoing operations might or might not require this way of working. Try this - once you come up with your strategy for the quarter/year (e.g. your OKRs) assess each element according to uncertainty, complexity, dependency, and impact. Then, based on this analysis, choose the ones that would benefit the most from an “evidence-based management approach” and plan how to manage them this way. This might mean organizing a cross-functional, empowered, focused team of the portfolio company employees and external SMEs (if relevant) that will work in short cycles to create useful increments of value in this area and review them frequently with other stakeholders. It might mean creating high-level “Goals” and providing people with clarity on the Bet while allowing them to explore alternative ways to achieve the desired outcomes via trial and error in the trenches. Replacing the Engine Mid-flight More often than not, these strategic interventions will need to occur in parallel to continuing to run the business as hard as ever. People struggle to balance their day job (Company **#1**, the current company that needs to continue running) and transformation work (Developing Company **#2** — the one we are working to create) — how much capacity to assign to each? Does managing the day job and transformation work as part of the same bucket make sense? Who’s in charge of each type of work? Who mediates when there are conflicts? I hear from CEOs in these situations that they frequently need to get involved in resolving these conflicts between the day-to-day and the transformation. This results in delays, frustrations, and feelings of disempowerment. The environment is even more volatile if this transformation also coincides with other bigger company changes (e.g., new leadership, new investors/owners). Another common friction/frustration area is goal-setting. What should we focus on now? What’s realistic to achieve? Do we involve people who will do the actual work in goal setting? OKRs are a popular goal-setting mechanism. But they’re not as trivial to implement as they might seem… One common anti-pattern is to set too many OKRs, top-down. ( A better way is to provide alignment via Objectives and let teams come back with realistic Key Results. There’s much more to say about the effective usage of OKRs in a PE environment, maybe later…) This balancing act between operational and transformational work, alignment, and autonomy is a key area of focus for business/organizational agility. In my experience, Patterns such as “product ownership” and “developers,” while they sound very IT/product-centric, can come in handy. Organizing around Bets Another common sign of trouble is when teams are overly dependent on other teams to the point that their progress is frequently blocked. They spend precious time coordinating and managing across the organization rather than executing. This can manifest as leaders of teams being extra busy in trying to coordinate the complicated network of dependencies and the desire for more and more “coordination/management layers” such as PMOs, project managers, and the like. A preferred play is to [reorganize around value](https://www.linkedin.com/pulse/improving-focus-alignment-organizing-around-okrs-managing-yuval-yeret) — rethink team structure and bring together the people collaborating closely in executing the transformation into empowered, focused teams that self-manage with minimal overhead. These teams might include people from different functions — for example, Product Management, Marketing, Sales Enablement or Finance, Legal, and HR. This virtual team structure should be aligned with the key initiatives the company is focused on. ### The New Frontier for Agility Agile was born in software development and has been widely adopted in IT and Product organizations to the point that there's little argument that product/technology organizations should operate using agility principles. More recently, other functions, such as Marketing, have adopted these agility principles and practices. These are useful stopgap measures on the journey toward real organizational agility. The next frontier I'm seeing in a couple of early adopter organizations is the evolution towards a more holistic definition of "development" that I explored in this article - developing the company's capabilities. In Scrum, this would mean that the **company is the Product.** https://youtu.be/eU9CwIv7ONo --- _If your company is hitting the scaling ceiling — losing innovation speed, increasing coordination overhead, or struggling to move from strategy to execution — [let's explore what is getting in the way](/work-with-me)._

Should SAFe Strategic Themes include gradable Key Results?

Yuval Yeret — Fri, 16 Feb 2024 00:00:00 GMT

[Strategic Themes in SAFe](https://scaledagileframework.com/strategic-themes/) represent strategic choices at the Enterprise/Portfolio level that should guide decisions throughout the portfolio. A qualitative Objective accompanied by a quantitative, valuable, and measurable evidence-oriented Key Result connected to a portfolio KPI is a great way to make sure the strategic theme is pointing toward desired outcomes without going into too much granularity. So far, so good. These OKRs are supposed to be gradable - including specific expectations of what success would look like. (E.g. Improve Net Promoter Score from 35 to 60). This raises an interesting question: How does the LPM team know that this specific target is achievable? when we set Strategic Themes - we might know how far we WANT to go, but we don't know how realistic that is. To use the example below - we might want to get to a Net Promoter Score of 60 - but is that realistic? at all costs? If we commit to Strategic Theme Key Results prematurely, we risk business predictability and losing people's connection and motivation. It is similar to the dynamic in PI Planning - The ART teams determine what objectives are possible. They're provided a direction, but they figure out how far they can go in that direction. Back at the portfolio - Higher confidence in the target should similarly be based on some involvement/consideration of the draft targets with a reasonable representation of the development value streams that will be involved in working towards them. This should be light weight unless there's something material about a specific KR. With this in mind - If you want to create better alignment, respecting the people in the portfolio, here are some tweaks to try: - Consider drafting Strategic Themes with valuable, measurable, but not gradable Key Results. To use an example from the SAFe article - Instead of "Improve Net Promoter from 35 to 60," use "Improve Net Promoter Score from 35 to X (60?)." - Draft Strategic Themes as described in the current guidance - but consider the Key Results in draft status - to be confirmed based on bottom-up cascading back from Teams to ARTs to the Portfolio. - My favorite approach is to build quicker confidence and alignment around Strategic themes through a Strategic planning workshop that uses draft Strategic Themes as input and then uses a structure similar to PI Planning to cascade/inform value streams / ARTs / Teams who will draft their own objectives and key results, integrate and validate the Strategic Themes. Participants could be the LPM + Solution ARTs + ARTs stakeholders across the portfolio. Beyond specific fixes - more importantly, go back to first principles - in this case, SAFe principles - when thinking about the process of setting Strategic Themes and OKRs in general. (Assuming Variability and Preserving Options, Decentralizing Control, Unlocking the intrinsic motivation, Cadence and Synchronization come to mind here) ## Are you seeing the dysfunction I'm talking about in your organization? Do my suggestions resonate? _OKRs work best when they're connected to how teams actually operate. [Explore OKR advisory](/work-with-me/strategic-alignment-and-execution-at-scale-leveraging-okrs) or [let's talk](/work-with-me)._

Yuval's Journey to Scrum | Expert Insights & Tips

Yuval Yeret — Sun, 04 Feb 2024 00:00:00 GMT

Join Ryan Ripley as he delves into Yuval's comprehensive journey into the world of Scrum, exploring the various facets that have shaped his career and contributions. In this Episode: [00:00](https://www.youtube.com/watch?v=fCL4p1ukURU&t=0s) - Warm Welcome to Yuval Yeret [04:05](https://www.youtube.com/watch?v=fCL4p1ukURU&t=245s) - Yuval’s Professional Background and Introduction to Scrum [08:30](https://www.youtube.com/watch?v=fCL4p1ukURU&t=510s) - The Turning Point: Adopting Scrum in Yuval’s Leadership Role [12:45](https://www.youtube.com/watch?v=fCL4p1ukURU&t=765s) - Yuval’s Motivations and Realizations in Choosing Scrum 17:20 - The Evolution of Yuval’s Perception of the Scrum Master Role 22:35 - Key Advice for Aspiring Scrum Masters from Yuval What You'll Learn: Yuval Yeret’s multifaceted background and his initial steps into the Scrum framework. The pivotal role continuous integration and leadership played in his Scrum adoption. Insights into Yeret’s journey from a leader to a professional Scrum trainer. The importance of empowerment in the Scrum Master role and its impact on team dynamics. Practical tips and resources for those seeking a Scrum Master career. https://www.youtube.com/watch?v=fCL4p1ukURU

Professional Scrum Trainer Spotlight w/ Yuval Yeret

Yuval Yeret — Fri, 12 Jan 2024 00:00:00 GMT

I'm featured in the latest Scrum.org Community Podcast PST Spotlight series. Dave West and I talked about my background in DevOps and product development and how I developed my passion for agile and empiricism that has developed over the years. We talked about how I became a PST while introducing Kanban to the Scrum.org community, and my focus these days e.g. bringing the Scrum and Flow spirit to OKRs and scaling Scrum's ideas in non-traditional environments, such as marketing, consumer goods and biotech, with a focus on integrating Agility and Evidence-Based Management to create a healthier OKR-based operating system. We also touched on some trends in the Agile/Agility movement/industry such as the shift from practices to first principles and patterns. Always fun to have a chat with Dave. Check it out! ## [https://www.buzzsprout.com/872401/14293483](https://www.buzzsprout.com/872401/14293483)

The Fixing OKRs Live Stream Series

Yuval Yeret — Fri, 05 Jan 2024 00:00:00 GMT

https://youtube.com/playlist?list=PLQhWcxnkPo7dYyggVl3aATgg3O2Z6F3vd&si=7cvRdCK7yC\_gQhQD

Fixing OKRs Play List

Are you struggling with OKRs? Tune into my Fixing OKRs Videos, which were recorded in a set of live streams earlier this year. If you want to dive deeper - [check out my OKR advisory and coaching offerings.](/work-with-me/strategic-alignment-and-execution-at-scale-leveraging-okrs)

Deconstructing SAFe Criticism - Focusing on the SPC role

Yuval Yeret — Thu, 04 Jan 2024 00:00:00 GMT

[](https://www.youtube.com/@yyeret2) https://www.youtube.com/live/0KIXhw-koBI?si=17rYZqYqZcjJWAWG There’s a lot of criticism out there about SAFe (Scaled Agile Framework). Leaders aiming to achieve agility at scale often find the landscape confusing and, at times, frightening. Some of the criticism is fair and worth addressing. Some is pure FUD mongering (Fear, Uncertainty, Doubt) As a Professional Scrum Trainer AND a SAFe Fellow/SPCT I get a first row seat for these "framework wars" and find myself in a unique position to not only understand this criticism but also work towards addressing it — whether by better explaining SAFe or evolving the ecosystem to reduce common anti-patterns. Some of the most common criticisms revolve around poor SAFe implementations, which I often refer to as “SAFe Theater.” These are implementations that look agile on the surface but are just going through the motions without true understanding or commitment. Much of the criticism stems from the fact that organizations often rely on individuals who lack adequate experience and understanding of agility to implement SAFe effectively. --- ### Understanding the SPC Role The SPC (SAFe Practice Consultant) is the individual certified and positioned by SAFe to lead an organization's SAFe journey. Responsibilities include embodying an agile mindset, leading change, implementing SAFe, coaching, and training, particularly around flow and accelerating business agility. SAFe is explicit about defining different roles at various organizational levels. These include Scrum Masters at the team level, Release Train Engineers (RTEs) at the ART (Agile Release Train) level, and SPCs who work across teams, portfolios, and the broader journey. SPCs often operate within a Lean-Agile Center of Excellence, providing strategic guidance and coaching across the organization. This means that the SPC is a crucial role to the successful understanding and application of SAFe in the enterprise. You can compare it to the role of an experienced Scrum Master that focuses on successful understanding and application of Scrum at the organizational level. --- ### Becoming an SPC To become an SPC, one must complete the Implementing SAFe class, a four-day program covering principles, practices, mindset, and implementation strategies. While the class is valuable, the problem lies in what follows: After passing a multiple-choice exam, individuals are certified as SPCs, with no real test of their ability to train, coach, or implement SAFe effectively in the real world. In other words, becoming an SPC is very similar to becoming a Professional/Certified Scrum Master, Product Owner, or Project Manager (PMP). --- ### Strengths of the SPC Model When experienced professionals (e.g., VP of Engineering, PMO leaders, Agile coaches) attend the Implementing SAFe class, they gain valuable insights that enhance their ability to drive agile transformations effectively. These leaders often become strong partners for change, and the SPC certification, when paired with real experience, can be an effective tool for scaling agility. The fact that SAFe includes a "train the trainer" model where SPCs can train others in their organization, goes one step further than the Scrum model. Scrum Masters are expected to coach/train/mentor their teams and organizations. In the Scrum world, the Scrum Master focuses on informal on the job style training. In the SAFe world SPCs are enabled to deliver formal certified training. In the right hands, this model can help organizations scale training faster with reduced reliance on external training. The "Train the Trainer" fan-out model has helped SAFe spread fast. --- ### Challenges and Criticisms The problem arises when organizations or consultants treat the SPC certificate as sufficient proof of expertise. Without proper experience, new SPCs are often thrust into positions where they are expected to deliver training or lead transformations without adequate knowledge or capability. Some consultants simply add the SPC credential to their resume to make more money, and organizations sometimes have unrealistic expectations, assuming the certificate alone is enough. When poorly equipped SPCs deliver training or facilitate implementations, it results in what I call “SAFe Theater,” where people are just going through the motions without real understanding or belief in what they’re doing. This isn't a problem limited to the SAFe world, of course. The Scrum Master is another example where the certification has helped Scrum spread, but also created dysfunction where organizations rely on the certification in leu of real agile expertise - leading to widespread Scrum/Agile Theater. --- ### Opportunities for Improvement Enterprises need to adjust their expectations of what the SPC certification means. They should look for outcomes, experience, capability, fit as well. Organizations should ask probing questions during the hiring or contracting process. For example, asking SPCs to share stories about their experience coaching, training, or facilitating value streams can reveal much about their capabilities. Additional certifications like Professional Scrum Trainer (PST) or PSM III can also indicate broader expertise and experience. As a community, we must discourage unprofessional or unethical behavior by setting clearer standards for what professionalism looks like. This could include agreeing on what readiness looks like for training or consulting and expecting an SPC to say NO when they're not yet ready to take on certain responsibilities. --- The SPC model has tremendous potential, but we must be willing to address the real challenges that come with it. By doing so, we can build a stronger, more credible ecosystem that genuinely helps organizations achieve agility at scale. If you'd like to discuss the right approach for developing and leveraging SPCs in your organization - [let's discuss.](/work-with-me/scale-agility-leveraging-the-scaled-agile-framework) [![](/assets/images/blog/Deconstructing-SAFe-Criticism-SPCs_2024-01-04_16-02-56-1024x862.png)](https://app.mural.co/t/yeretagility8646/m/yeretagility8646/1702562019724/8b50740ee66f5e2d52d6a462cfa0fb437b4655b5?sender=u97fdbbf1d0f5276534c34163)

Mapping Flow Metrics in SAFe, Professional Scrum with Kanban, Project 2 Product and Evidence-based Management

Yuval Yeret — Thu, 04 Jan 2024 00:00:00 GMT

Suggested New Year Resolution - Improve Flow of Value! Start with Measuring Flow... but how? There are different flow metric taxonomies - how are they similar/different? In this live stream, I reviewed the PSK, Project 2 Product, SAFe, and EBM flow metrics taxonomies and how they map to each other. I also discussed the bigger picture and how flow metrics relate to and support outcome focus / evidence-based management. Check it out, and tune in to upcoming live streams by subscribing to my YouTube channel and/or [following/connecting on Linkedin](https://www.linkedin.com/in/yuvalyeret/).[](https://www.youtube.com/@yyeret2) https://www.youtube.com/live/f7Of98jN28I?si=gsBIGCXlzvtBhTgv If you're interested in the resources/links I shared - [here's the Mural with the links](https://app.mural.co/t/yeretagility8646/m/yeretagility8646/1696534430849/05f040a8a7f2d6f498142aca6385546f8d033213?sender=u97fdbbf1d0f5276534c34163): [![](/assets/images/blog/Flow-Metrics-Landscape_2024-01-04_17-22-59-919x1024.png)](https://app.mural.co/t/yeretagility8646/m/yeretagility8646/1696534430849/05f040a8a7f2d6f498142aca6385546f8d033213?sender=u97fdbbf1d0f5276534c34163) A significant part of my consulting practice is focused on helping organizations establish and accelerate flow - including the [Accelerating Flow workshop](/work-with-me/scale-agility-leveraging-the-scaled-agile-framework/accelerating-flow-workshop). if you're interested to learn more [let's discuss](/accelerating-flow-workshop 'Accelerating Flow Workshop')

Expanding My Collaborative Horizon - Teaming Up with Flow Sphere

Yuval Yeret — Mon, 13 Nov 2023 00:00:00 GMT

Today, I want to share a major business update. Last week I associated my SAFe SPCT (and Fellowship) with [Flow Sphere](https://www.flowsphere.ch/en_US/) as part of a strategic partnership between Flow Sphere and my consulting practice Yeret Agility. Flow Sphere is a premier boutique agile consultancy, SAFe [Gold SPCT Partner](https://scaledagile.com/partner-finder/partners/001d000002939BKAAY/), and Scrum.org PTN, led by [Sacha Czudek and Stephan Neck](https://www.flowsphere.ch/en_US/about-us/) - two of my favorite SPCTs. We share a common pragmatic perspective, with SAFe being just one approach to scaling agility. With Sacha and Stephan in Switzerland, [Nagesh Sharma](https://www.scrum.org/nagesh-sharma) in India, and now me in the United States, we now have both geographical breadth that aligns with many of the enterprises we're serving as well as the professional diversity through expertise in SAFe, Professional Scrum, Flight Levels, OKRs, Lean Startup and beyond. We've already had a chance to collaborate on a SAFe/Flow Pharma IT engagement. It is one example of the value we can unlock for our clients through this strategic partnership. I look forward to collaborating with Nagesh, Stephan, Sacha, and the team on shaping the future of the agile/flow sphere! If you have any questions about what this means - I'm happy to discuss! Best, Yuval

Vincenza Nigro - Global Franchise Lead - Hansa Biopharma

Yuval Yeret — Fri, 18 Aug 2023 00:00:00 GMT

## Yuval helped me bring the science and mindset of agile into the Biotech world. He advised me and my team on how to operationalize the agile best practices and apply them pragmatically and practically to our unique context - with a focus on transparency, empiricism, shared understanding, and empowerment. Yuval brings a wealth of experience across many industries and is a real partner in our journey.

OKR Implementation Tips

Yuval Yeret — Tue, 15 Aug 2023 00:00:00 GMT

## OKRs – Yet Another Silver Bullet It seems OKRs are the new “silver bullet” - VC/PE/GE Investors give John Dorr’s “Measure What Matters” book to their CEOs and strongly suggest that their portfolio companies use OKRs. While the idea of using OKRs to improve strategic focus and alignment with execution is great, things often go wrong in implementation. When I come to such an organization, I often see an environment where every project becomes an OKR, OKRs that describe outputs and activities, and OKRs that are siloed and departmental, sometimes even individually assigned. It's as if the organization took whatever way it used to manage work and slapped an OKR label. When that happens, leaders and investors reap none of the potential benefits of OKRs. Alignment isn’t improved, and people don’t have the context to make better decisions. They also don’t have the space to make decisions. The organization still exhibits the same micro-management siloed behavior that existed before introducing OKRs. ## OKR Best Practices Here are some tips for getting more alignment, empowerment, and focus using OKRs. First, understand that OKRs are there to help you align developmental work, not manage ongoing operations. For example, in the Marketing/Revenue world, you don’t need to use OKRs to manage ongoing marketing and revenue work. But you might use OKRs to align around moving to a PLG motion, focusing on plugging a retention leak. Secondly, the power of OKRs comes from creating alignment around outcomes and empowering people and teams to figure out how to achieve those outcomes. Set OKRs that focus on what you’re trying to achieve, not how to achieve it. Ask Why a couple of times to move from activity to output to the desired outcome. Another common problem is where leaders set OKRs in a vacuum – not considering the capacity of the organization to achieve the objective. Consider the big picture of operational and developmental work flowing across your organization. Consider a set of candidate OKRs and set a clear priority between them. Then, let people and teams PULL from the top of this list the OKRs they CAN achieve. (PS This is very similar to the concept of Backlog in Agile ways of working such as Scrum.) To avoid “Fire and Forget,” create a disciplined routine of creating transparency on what outcomes have been achieved, inspecting and adapting on a cadence that makes sense so that you can steer towards maximizing those outcomes. Allow, welcome, and even encourage adjusting actions and activities as needed to achieve the objective. And be open to the possibility that even the objective might change. ## Not everything needs to be an OKR Many organizations confuse OKRs and KPIs and struggle to determine which work to manage using OKRs. As mentioned, OKRs should be used for developmental/growth/change work. Let’s explore this in more depth by explaining the difference between KPIs and OKRs. Every organization balances running the business and improving/growing/scaling the business. Key Performance Indicators (KPIs) are the quantifiable measures used to evaluate our performance against our promises. You can also call them Key Promise Indicators. KPIs are used for ongoing operations – to run our business. Churn / Revenue / Conversion Rate / Throughput are all examples of KPIs. We monitor the KPI Dashboard to keep our business on track. Objectives and Key Results ( [OKRs](https://felipecastro.com/en/okr/what-is-okr/)) are meant to be about managing/guiding change rather than maintaining the status quo. OKRs typically describe a desired change in a KPI as the quantitative outcome associated with the qualitative objective. ## Interaction between KPIs and OKRs A typical journey towards becoming an evidence/data-based organization would include identifying key business processes or value streams, agreeing on a set of KPIs aligned with the outcomes we expect those streams to create, creating a baseline of these KPIs, and a routine for ongoing management. As part of that, gaps between desired and actual performance are identified, and objectives can be created to close these gaps. This is where OKRs are defined. ## A Business Example For example - one of these business processes/value streams is Revenue generation. One obvious KPI here will be Revenue. But Revenue is not an OKR! Improving Revenue could be an OKR, but it would be a mediocre OKR that doesn’t provide any help/context as to what exactly we want to achieve. Improving Expansion Revenue is somewhat better because it provides some guidance on where to focus. This OKR will require some new KPIs to measure it - e.g., Expansion Revenue - and the first Key Result might be to discern expansion revenue vs. straight renewals vs. new logos and establish a baseline. The team focused on this OKR would then figure out what projects/initiatives could move the needle on expansion and set a KR to capture their intent there and what results they are expecting in terms of the KPI. In this way - what you might call “development” work is tightly connected to “operational” work and aligned with the needs of the business- but managed in a different way that taps into creativity and optionality. ## How to manage work towards OKRs Another anti-pattern I see often is using traditional project/program management to manage OKR work. Most OKR work involving complex changes to our products, our business model, or key business processes is rife with volatility, uncertainty, complexity, and ambiguity to the point that plans don’t survive contact with reality. What works better is approaches to project/program management inspired by Agile software development. These approaches are incremental and iterative and emphasize cross-functional collaboration in tight feedback loops leveraging empiricism. In this context, it means to create a sequence of Increments that provide progress toward the desired output in alignment with the OKR. Each Increment is created in a cycle of planning, doing, inspecting, and potentially adapting. Companies use this approach to incrementally and iteratively design marketing campaigns, business model innovation, product-led growth plays, and other business capabilities. ## Closing Notes OKRs can be a powerful tool. They can also be misused and generate more damage than benefit. In this article, I provided several best practices for helping you tap into the power and potential of OKRs to help organizations align, focus, and execute. ## If you want to discuss these best practices and your context in more depth, Reach out to me and schedule a free OKR consultation session. _OKRs work best when they're connected to how teams actually operate. [Explore OKR advisory](/work-with-me/strategic-alignment-and-execution-at-scale-leveraging-okrs) or [let's talk](/work-with-me)._

What changed in SAFe 6.0 and what actually matters?

Yuval Yeret — Fri, 11 Aug 2023 00:00:00 GMT

What changed in SAFe 6.0 and what actually matters? A practical look at the updates that affect flow, teams, portfolio thinking, and business agility.

Adam Magen - VP Operational Excellence - Siemens Digital Industries

Yuval Yeret — Wed, 09 Aug 2023 00:00:00 GMT

## By having Yuval on board, we found not just an experienced professional but also a partner in our lean journey with a passion and commitment to coach and guide us until we achieve our goals. Yuval’s vast knowledge and experience along with keen analytical skills enable him to fit the lean principles into our organization’s DNA and to help us overcome difficulties and constraints without risking our short-term business targets. Yuval has many capabilities which make him highly versatile. He can swiftly move from strategy/blueprints to training a class, implementing methods/processes all the way to helping us through some tough issues through hands-on coaching. This makes Yuval very valuable and influential in our journey towards lean.”

Steve Lizotte - VP Engineering - NEC Americas

Yuval Yeret — Wed, 09 Aug 2023 00:00:00 GMT

Yuval is the best Lean/Agile partner I have ever worked with. Over the 2+ years of our working relationship, he has consistently brought a pragmatic and refreshingly direct approach to problem-solving, coaching, and training. He leans in, and rather than prescribing a canned academic/textbook solution, he works with us to truly understand our core problems and then prescribes a tailored solution that works best for us. We have measured significant improvements in schedule adherence, quality, and customer satisfaction. The results have been dramatic. In addition to working with our core development teams, Yuval has presented Lean/Agile fundamentals to senior executives within my organization and customers who participate in our Customer Advisory Board meetings. ## He is a no-nonsense straight-talker, and I unconditionally recommend him to anyone serious about agile transformation.

Enna Jimenez - Business Transformation and Quality Leader - IDEMIA

Yuval Yeret — Mon, 19 Jun 2023 00:00:00 GMT

## It was such a pleasure to work with Yuval. His attention to detail and training program were exactly what we were looking for. He has a way of communicating change in a way that is easy to understand. I absolutely loved working with Yuval and would encourage everyone to work with him. Would absolutely hire him and his company again! Thanks Yuval!

Kate W. Isaacs - MIT

Yuval Yeret — Mon, 19 Jun 2023 00:00:00 GMT

## Yuval is a highly experienced agile professional and trainer, a skilled interventionist, and an A+ team player in everything he does. He is highly skilled with clients in bringing his knowledge and intuition to help them meet their goals. Yuval is the best of the best.

Tyson Bertmaring - Head of Stewardship - Dyno Therapeutics

Yuval Yeret — Mon, 19 Jun 2023 00:00:00 GMT

## When I asked, “Who should guide us through our Agile journey?” “Yuval” was the reply, followed by the reasons. What I have experienced has been consistent. Yuval is knowledgeable and guides you by asking the right questions at the right time to get you and your team thinking. He has a knack for identifying the missing concepts and language and getting us to talk about those in such a way that we can improve how we work together. Most consultants tell you the answer; Yuval asks the right questions so you find the answer yourself.

Lean Stack - Lean Startup Continuous Innovation Framework

Yuval Yeret — Mon, 29 May 2023 00:00:00 GMT

LEANSTACK helps startup accelerators, university incubators, and venture studios build the next generation of entrepreneurs using battle-tested playbooks. I'm using this framework with entrepreneurs and intrapreneurs to help navigate the fuzzy front end before Product Market Fit effectively

Donald Reinertsen

Yuval Yeret — Mon, 29 May 2023 00:00:00 GMT

Donald Reinertsen is the "Don" of modern Lean product development and Flow. Don doesn't write or speak that often but whenever he does, advanced lean/agile practitioners and thought leaders listen! His book, [Principles of Product Development Flow](http://lpd2.com/) is a must read for lean/agile leaders and serious agilists.

Scrum.org - Home of Professional Scrum

Yuval Yeret — Mon, 29 May 2023 00:00:00 GMT

Scrum.org is the home of Scrum!™ What makes the content at Scrum.org especially useful is the fact that most of it is created by Professional Scrum Trainers like me.

The ART of SAFe

Yuval Yeret — Mon, 29 May 2023 00:00:00 GMT

Mark Richards is a SAFe Fellow and SPCT always advancing the art of SAFe. One of his great contributions is [SAFe City](http://www.coactivation.com/safecity/) which is a great simulation for WSJF and PI Planning.

Connecting OKRs, KPIs, OVSs, and DVSs

Yuval Yeret — Sun, 28 May 2023 00:00:00 GMT

A plain-language breakdown of OKRs vs KPIs vs OVSs vs DVSs — what each measures, why the distinction matters, and how they connect in a delivery system.

How Vendors Can Apply Customer Centricity

Yuval Yeret — Sun, 28 May 2023 00:00:00 GMT

How technology vendors can embed genuine customer-centricity into their product and go-to-market strategy using lean/agile principles.

Invitation-based SAFe Implementation

Yuval Yeret — Sun, 28 May 2023 00:00:00 GMT

A publication exploring how pull-based, invitation-driven approaches to SAFe adoption improve engagement and sustainability compared to mandated top-down rollouts.

Kanban Guide for Scrum Teams

Yuval Yeret — Sun, 28 May 2023 00:00:00 GMT

The official Kanban Guide for Scrum Teams — what it means in practice: adding flow metrics, WIP limits, and continuous improvement practices without abandoning the Scrum framework.

SAFe® Program Dependency Board Retrospective

Yuval Yeret — Sun, 28 May 2023 00:00:00 GMT

How to run a retrospective on your SAFe Program Dependency Board — identifying systemic dependency patterns and improving cross-team coordination.

Scrum Guide Companion for Leaders

Yuval Yeret — Sun, 28 May 2023 00:00:00 GMT

What does Scrum/Agile mean for you as a leader? How do I, as a leader, create the conditions in which Scrum/Agile can thrive? How can I support the Scrum accountabilities, artifacts, and events? The bad news is that the Scrum Guide doesn't provide answers to any of these questions. **The good news? I partnered with Dave West to write the Scrum Guide Companion for Leaders to close that gap.** The companion white paper answers the questions above. One conclusion leaders make when reading it is that there's a lot that they need to understand and take to heart in the Scrum Master leadership accountability. And that's by design. What if I'm using SAFe? some other scaling approach? some other homegrown form of agility? I think you will still find the framing in the companion useful - especially because whether you explicitly call it Scrum or not, Scrum has influenced most agile at scale approaches. My SAFe clients specifically do find it quite useful. Check out the [whitepaper](https://www.scrum.org/resources/scrum-guide-companion-leaders) and/or the [audio version](https://s3.amazonaws.com/static.scrum.org/web/English+Scrum+Guide+Companion+for+Leaders+Audio.mp3). Then ask yourself, "What did I just learn here? So, what does that mean for my role as a leader? Now what?" If you want my take on leading in Scrum, [grab some time on my calendar,]({{DISCOVERY_URL}}) [and let's discuss.]({{DISCOVERY_URL}}) **The companion is based on my experience helping leaders navigate the difficult choices needed to close the curtain on agile theater and create a professional scrum environment in their organization.** **To learn more check out the [Agility Strategy Workshop](/agility-strategy-workshop 'Agility Strategy Workshop') and [Fixing Your Agility](/work-with-me/fixing-your-agility).** [![Scrum Guide Companion for Leaders Cover](/assets/images/blog/Image-9-4-24-at-5.58 AM-998x1024.jpeg)](https://www.scrum.org/resources/scrum-guide-companion-leaders)

How do you scale Agile Marketing beyond one team?