The PM Tension Series: Part 3

Welcome and Webinar Introduction: Why Speed Without Discipline Breaks Teams

Kenny Kranseler | 00:00:00 – 00:00:52
So, we’ll get started. Um, this is part three of our PM tension series that was derived from some uh study we did from with product managers about some of the tensions they face. Um, and today is part three will bear part three in our last in that series. And today we’re going to talk about why speed without discipline uh tends to break product teams. So Tom will be leading and I will be supporting.

Um we can quickly introduce myself. I’m on the right. Um you can see from my picture I’m a principal consultant and trainer at Productside. Have been for about the last seven years or so. Prior that it’s been 25 to 30 years or so as a product manager, product director, VP of product, chief product officer. You name it, I’ve done it. And I’ve been having a blast here at Productside since.

Tom, you want to introduce yourself?

Tom Evans | 00:00:52 – 00:01:32
Yeah, absolutely. And I was just going to say you look more like your picture than what I look like in that picture. But you need a new picture.

Tom Evans. And I’ve been with Productside for uh almost 16 years uh with an opportunity to work with a lot of great people around the world helping them and their companies transform their practices and product management. So I’m excited to be here and speak on this topic because this is actually uh up there with jobs to be done. This is again one of my favorite topics to talk about.

About Productside and How to Participate

Kenny Kranseler | 00:01:32 – 00:05:57
Excellent. All right. Um, so let me go to the next slide, Tom.

So, I’m I’m going to start by welcoming you all to this and give you a little bit of introduction into Productside. Um, who is the team that’s driving today’s webinar? Uh, at Productside, um, we know how hard it can be to deliver really great products that people not only use but truly love. And it could be anything from aligning stakeholders, predicting customer needs, managing endless backlogs. We’ve seen some or most or all of that. Um, and that’s really why we’re here. Um, to be your outcome-driven product partner.

Um, and we don’t just provide solutions, but we tailor them to each company’s unique challenges. Um that enables things like hopefully complete solutions to help you transform everything from strategy to execution. We’re there to help you along the way as you make your trans transformation to being an outcome-driven product-driven uh company and we as as I noted we tailor what we do uh to your needs, understand your context. We know that each company’s challenges are unique, their journey and product managers are unique. As a result, some of our solutions and we have a whole bunch of people like Tom and myself and probably a bunch of folks that are even better than us that really act as an extension of your team that works to make sure that you’re successful and we are thrilled to have you all uh with us today.

So, let’s dive in a little bit and start to help your product team thrive.

And um I encourage you to ask questions, lots of questions. Um we want to keep this session as interactive as possible. Within your um window, uh you will see a both a within your Zoom window, you’ll see both a chat and a Q&A. You can use either to ask your question. And the first question I’m usually asked is, can I watch this recording later and can I share it with my other my um other coworkers who probably can get value out of this but didn’t necessarily respond to this invitation? The answer to that is an absolute yes.

Um, everybody that comes to this webinar will get a link to the recording and we probably even put one in here uh during the session as well. Um as I mentioned, use the Q&A feature, use the chat feature. Uh keep the energy up, don’t hold back. Um really our hope is that um this is your time in which we want you to get the most out of the session as as we go through it.

Um one other little plug that uh I want to provide out there is we do have a LinkedIn group that I encourage you all to join, sign up with. Take a moment and um follow the invitation. There’s a QR code in here. And our LinkedIn page is really more than just a place to follow. We’re doing a Productside. It’s really a community. Um, and when you join that community, you’ll get a whole bunch of benefits. Things like leadership best practices that hopefully can inspire you and your growth in your role. Uh, we set up a bunch of conversations about what product management is, how it fits in, some tips on how you make it more impactful, and it’s really an opportunity for you to network with other product management professionals who are probably sharing some of the same goals, some of the same objectives, and yeah, some of the same challenges you are.

So again, scan the QR code um on the screen. You can join instantly or follow the link that we probably put in the chat. We really are happy to hear from you, swap ideas, keep that conversation going um on topics from today’s session or beyond uh so we can all work together to build stronger product management community um as has as as a joint opportunity.

And without further ado, I will um bring Tom on board who’s going to drive us through our key topic today about um how not to go too fast and make sure that we get things done effectively.

Agenda: The Tension Between Speed and Discipline

Tom Evans | 00:05:57 – 00:06:24
Yeah, absolutely. So, thank you.

So, this just an overview of what we’re going to be talking about, but first, I want to really talk about the tension that does exist out there. And I’m sure many of you feel it. I’ve I know as I’ve worked through uh with companies, I’ve I’ve seen them experiencing the same tension and expressing it.

Then I’m going to start talking about what how we need to be thinking differently and that’s all this uh thought around going from output to outcomes. Then we’ll talk about ways that we can actually accelerate value delivery. So we’re going to have a change of focus here. And then you’re going to say, well, okay, this all sounds great. What are some things that we can do to start to make that transition? And so that’s what we’re really going to do wrap up with is helping you get some ideas and thoughts on how to start making a transition to uh reduce that tension that exists out there.

The Feature Treadmill: Why Teams Feel Fast but Stay Stuck

Tom Evans | 00:06:24 – 00:08:30
So let’s get into just talking about the tension.

And I know as I’ve worked with companies around the world, I see a lot of companies where their executives have pressure on the product management team to be able to say you have to deliver a particular feature by this particular time. By the way, we got all this other stuff and you have to deliver that too. And so there’s a lot of executive pressure mandating here are the features that have to uh be deliverer and what we do is there’s such the pressure to do that that we have no time to do any discovery work and so we skip discovery we move right on into uh building the output and delivering that output.

And I will say um I know that as I’ve worked with companies that do, you know, this detailed planning that looks out over you know several months or three months is often very common and say this is what we’re going to deliver in this time. I will always ask them how much of that did you actually deliver and they will say uh 30 uh you know 50% of it maybe.

And so, you know, we’re already in a conundrum there. But then we deliver it and we find out well that’s not really what the customers were needing or their expectations. Maybe we made some shortcuts to be able to make a delivery on a feature. You know, we start fingerpointing around who is uh who’s to blame around that. And that just creates more pressure in the organization. And so here we are running on this feature treadmill.

We want to do uh customer discovery type work, but in the end that completely gets blocked out. And so that’s really the tension that is existing there is that pressure between here’s what you have to deliver versus knowing are we delivering the right things.

Poll #1 – What Is Your Team Rewarded for Most?

Tom Evans | 00:08:30 – 00:10:01
So we have a poll here and uh that we’re going to put up here and four options there. But what’s your team rewarded for most? Shipping on time, stakeholder satisfaction, adoption or retention outcomes, risk reduction and quality, or the quantity of output like how many uh story points or how many features did you deliver or did you deliver all the features that uh we asked you to do?

And I know you as a person may actually have several of those that are that are uh up there on the list, but we’re going to ask you to vote just on one of those. So, let’s see if we come up there.

Okay. Some folks are chiming in on us. See if Yeah, let’s get about another uh five seconds here because I think we got a pretty good quorum in place.

Maybe we can share it back up. All right, go ahead and shut that down and share the results here.

All right, hopefully you are seeing here on your screen uh the results on that. And I would say, Kenny, no surprise to me, 41% focused on shipping on time.

Kenny Kranseler | 00:10:01 – 00:10:12
That’s over 50% if you add quantity of output.

Tom Evans | 00:10:12 – 00:10:37
Yeah. Yeah. There’s another 12% on quantity of output. So that’s over 50% that are focused on, you know, the output uh on schedule on time. Some folks 30% are on adoption and retention. Yeah. Yeah. That’s actually pretty good to to be thinking about the customer uh need there. And then stakeholder satisfaction is the other one. Nothing around risk reduction or quality. So that’s uh I’m not sure how to take that, but [laughter].

Output vs. Outcomes: Why the Distinction Matters

Tom Evans | 00:10:37 – 00:15:40
So why do we focus on output? Well, it’s because it’s visible and measurable.

And what we really want to be focused on is outcomes. So what impact are we making for the business or are we more importantly making for our customers? That’s what we really want to see is both a positive impact upon our customers. And if we’re making a positive impact on our customers, that’s going to lead toward a positive uh impact on our uh organization.

Now does this mean output is not important? No, output is important. But output needs to be prioritized in terms of the context of what outcomes are we trying to achieve.

And I think what I see often in organizations—and I had a meeting earlier this week where this really stood out to me—is we got a list of, we got these big backlogs with hundreds of items in them. We run some kind of prioritization and we say, “Okay, here’s our prioritized things that we’re going to work on,” or that comes from the sales team to close the deal or it comes from management to close the deal. And we aren’t ever really taking that look and saying, “Well, what’s the outcome that this is achieving? How is this helping our customers? How is this contributing to our overall business?”

So why do we focus on output? It’s visible and measurable. There’s also this perception of predictability or certainty that the better we define all of these outputs we’re going to deliver, we have much more control over that and much more certainty.

And as I already shared, as I speak with companies that have this detailed planning in place—companies especially that do SAFe—they are rarely delivering much more than 50% of what they committed to or planned.

We also think it helps us with capacity planning. And then of course stakeholders are always requesting specific output.

It creates the illusion that we’re moving quickly and that we have control over that. But in the end, are we really delivering the best customer value?

Why Output Focus Feels Good — and What It Breaks

Tom Evans | 00:15:40 – 00:20:43
So, you know, are there some benefits to output? Well, at least it creates the perception of clarity. Okay. It does give us a way to measure some level of momentum. It probably does accelerate some of the decision-making that we make. Uh executives like to see how many lines of code or how many story points are being delivered because that’s clearly measurable to them and a measurement of progress.

But when we focus primarily on output, what happens?

Discovery loses.

And I cannot tell you how many classes that I have taught where we have emphasized the importance of doing discovery work and you have almost everyone in the class saying, “But we don’t have time to do discovery.” Our executive teams don’t see the value in discovery because they can see code being written. They can see stories being delivered. Um and so I don’t want to make this just software-oriented, but you know, they can see product development being completed and milestones being hit on a project plan and that’s progress to them.

But when we’re doing discovery, we don’t have clear measurable ways to demonstrate that—or at least they aren’t able to see that.

Often we skip discovery because our stakeholders really feel like we already know what our customers need. We know our customers. This is exactly what they need.

And then I know that I’ve been asked this in the past and I know other product managers are being asked—they’re being asked to create roadmaps that look far into the future. If you’re in a software world they’re saying what are you going to when are you going to deliver something here a year and a half or two years from now? If you’re in a physical product world you may be asked for those same commitments two years or three years out.

So there’s that pressure to commit even when we are facing a lot of uncertainty in terms of what needs to truly be developed.

So here’s the impact that we run into if we focus on the output. Well, it definitely causes us rework because if we just proceed working on delivering a product or capabilities in the product without any of that validation through discovery, we’re not going to have delivered the right thing. There is a chance we can do that, but I often see that’s not the case and we have to go back and do rework on that.

We end up growing our technical debt because sometimes to deliver and meet a schedule we take shortcuts and we say we’re going to catch up on that later on and we’re always under pressure to deliver more and more and so that technical debt can sit there.

We miss opportunities to innovate and deliver true customer value and differentiation. It causes us to miss changes in the marketplace because when we’ve committed ahead of time and put a rigid plan in place, it makes it harder for anyone in the organization to say, “No, this isn’t the right direction. We need to change.”

And I know in my own experience, as well as with the companies I work with, everybody’s feeling frustration because executives and other stakeholders are saying deliver this, it needs to be delivered by this time frame. We’re telling them we can’t do that. They say, “Do it anyway. Work harder.” We end up not meeting those schedules. People become frustrated. There’s fingerpointing. It doesn’t create the healthy environment that we want to have in terms of a product development practice.

Kenny, any other examples that you have seen?

Kenny Kranseler | 00:20:43 – 00:21:27
Oh, I see it all the time. I was working on a specific project and there was the dead head—this is the right thing to do—and we did it. We even took shortcuts. We ignored our beta responses where we had a huge bug. And as a result we wound up shipping a hardware product, of all things, in which the products that we shipped to retail to be sold turned into really good bricks or paperweights because they certainly couldn’t do what you were trying to get done with them. So even though the feedback was there, we had such high certainty, we ignored it.

Why Outcomes Create More Real Speed

Tom Evans | 00:21:27 – 00:24:02
So why do we want to focus on outcomes? While we can measure the activity with output, it’s really the impact that we want to be able to measure.

One of the things that I really love, and this is one of our colleagues that I heard say this a few years ago, is that when we’re focused on outcomes, that gives us optionality in terms of making decisions on how we’re going to deliver on that outcome. Because what we might discover is that the capability or feature that we thought we needed to deliver that outcome is not the best option.

So by focusing on the outcome versus already committing to that output, we have options available to us.

That also gives us optionality in terms of how we implement a specific capability in our product. I know for myself that I have often defined requirements and embellished them with everything that I ever thought I might want to have within that capability. And what I really discovered is there’s probably 20% of it that is truly delivering the right value and the rest of it has some value, but it’s a small incremental amount. And so we’re investing in a lot of capability that’s actually not the key part of what is driving value.

I personally have found that outcomes are more predictable to deliver than output. Because if I define an outcome, I have optionality in how I deliver on it. That’s much more predictable than just delivering output.

And this quote here I love, you know, the art of maximizing the amount of work not done. That’s really one of the things we want to be thinking about as product managers—how can we deliver the maximum value with as little work as possible? Not shortcuts. Not bad value. Great value that is most important.

Kenny Kranseler | 00:24:02 – 00:24:20
I like Einstein’s quote on this one too, Tom. We should listen to Einstein. He says,

“Any intelligent fool can make things bigger and more complex, but it takes a touch of genius and a lot of courage to move in the opposite direction.”

Poll #2 – How Is Process Perceived in Your Organization?

Tom Evans | 00:24:20 – 00:26:57
Well, let’s move into our next topic here about accelerating value delivery because that’s what we really want to achieve. And part of the underframing part of this is how do we put some level of process in place to help us in terms of accelerating that value delivery.

So our second poll and final poll here: how is process typically perceived in your organization? Is it a helpful decision framework, necessary but painful, bureaucratic overhead, or something we figure out our best way to work around?

I worked in an organization a number of years ago and we went through the ISO 9000 certification process and there’s a lot of process that you put in place. That’s one of the things that I experienced—wow, some of this just felt like bureaucratic overhead.

So let’s go ahead and end that poll and share these results.

Almost 50%: necessary but painful. Bureaucratic overhead: 24%. Something to work around: 6%. And only just under 25% responded that it’s a helpful decision framework.

That really sets us up nicely for what we want to talk about.

You Have to Slow Down to Speed Up

Tom Evans | 00:26:57 – 00:30:07
One of the things I love to say in my class is you have to slow down to speed up.

That slowing down means that we really think about and understand and discover what our customers truly value, what’s important to them, using frameworks like jobs to be done and desired outcomes and identifying what their problems are.

That is the important upfront discovery work that we need to do.

Discovery can also be about what’s the best way to implement this capability in our product. So if I take the time and do that discovery work, it doesn’t speed up the quantity of work I deliver, but it will speed up the value of what I deliver. It will speed up the impact that I’m making for my customers and for our organization.

And that leads me to a question I ask: is the process serving us or are we serving the process?

When we are serving the process and the process is not serving us, then it absolutely becomes bureaucratic, painful, and something we want to work around.

The right amount of process helps us reduce risk, creates learning loops, and clarifies decisions and who makes them. The goal of process is not to slow us down, frustrate us, or make more work. It is to help us be more effective in the work we are doing.

What Good Lightweight Process Actually Looks Like

Tom Evans | 00:30:07 – 00:33:28
So let’s talk about good process.

We want to focus on outcomes. We want to make sure the process empowers discovery. It should be adding value, not just creating control. There might be a little control needed because we still operate inside the context of the business, but the process should create flexibility to respond to market changes.

When I think about lightweight mechanisms that support good process, some of the things that are valuable are:

• Product strategy
• Outcome hypotheses
• Tiny acts of discovery
• Being data driven
• Team working agreements
• Clear decision rights
• Feeling empowered to say no

One of the things that I emphasize with organizations is to have a core team. Who is that small group of five to seven people that are making the day-to-day decisions? Have a team working agreement. Include decision rights. But the final thing is that we want product managers to feel empowered to say no—and we are mainly empowered to say no if we are doing these things that are listed above. Having the strategy, doing acts of discovery, being data driven—those are the things that empower us to say no.

Kenny Kranseler | 00:33:28 – 00:35:33
A lot of it comes from understanding what assumptions are you making and how do you challenge and validate some of those assumptions.

The Productside Blueprint: Lightweight Process for Real Delivery

Tom Evans | 00:35:33 – 00:36:38
Well, if you’re looking for some lightweight process, we definitely highly recommend the Productside Blueprint.

The goal of that is to give us best practices to help guide the discovery work. So what we have under Discover before we start getting into the Creating or the Building of the product—and this can be as lightweight as you need it to be. If you want to make it heavyweight you’re able to do that. In some industries it does need to be a little more heavyweight. But it really is a lightweight approach of thinking about how do we identify what we’re going to build, how do we make sure it’s the right thing to build, how do we build it, and then how do we make sure as we launch it into the market it is driving to and achieving the targeted outcomes that we wanted it to achieve.

How to Make the Transition: Reanchor on Outcomes

Tom Evans | 00:36:38 – 00:40:47
So what do we have to do here?

We have to reanchor the teams on outcomes. We need to start with senior leadership and reframe things in terms of business value and customer value—not just output.

We as product managers need to take our roadmaps and move them into a strategic focus and outcome-driven focus and use that as the framework for how we start defining what we’re going to build.

We need to implement a required discovery cadence. Set the expectation that discovery work will be done. That discovery can be done before development starts and it can also happen in parallel with product development.

The third point: identify those unknowns or those risks and prioritize them. Those are the areas where we need discovery. I found for myself as a product manager that when I looked at a big list of things to deliver, I was never completely clear on what kind of research should I do. But once I started identifying the unknowns and the risks, that created clarity around what those tiny acts of discovery needed to be.

Make sure we have well-defined metrics—not just success metrics for your product, but health metrics too. Those are indicators of whether we’re progressing and whether the product is performing as expected.

And finally, be data driven. If you have products right now that don’t collect the data you need, or you don’t have access to it, think about how to make your products generate the data that will help guide better decisions.

And yes, that’s true in software. But in the world of physical devices, many are now being enabled with digital technologies, which means you can gather more useful signals there too.

Kenny Kranseler | 00:40:47 – 00:41:15
One of the things I see, Tom, is teams tend to do a good job on zero to one—when we’re first defining the product and doing discovery. Then once they deliver the thing, they stop thinking about it. They’re on to the next one.

Tom Evans | 00:41:15 – 00:42:20
Exactly. That’s where I see product managers often spending most of their time in Create and not enough in Discover or Deliver. We aren’t always sitting there watching to see how the product is performing from its technical capabilities to the business outcomes and customer outcomes that we wanted to achieve.

Productside Playbook: Practical Templates for Sustainable Momentum

Tom Evans | 00:42:20 – 00:43:39
So you may be asking, well, what can I do? Are there any tools out there that can help me do that?

Absolutely. We have our Productside Playbook, which is a set of I think about 27 different templates that cover all of these things that we’ve been talking about. And I’m going to highlight five of those.

• The first one is an outcome and strategy guided discussion. So if you’re a product leader, this is a great tool for you to use with your product managers to walk through and answer questions around who are the target markets, who are the customers we’re serving, who are the key personas, what are they trying to achieve, what are their important outcomes, what are the outcomes of the business. This is also a tool for an individual product manager to take to their director or VP and say, “I want clarity in terms of what this strategy is and what are the goals of our organization.”

Kenny Kranseler | 00:43:39 – 00:44:19
If you’re a product manager that doesn’t have the answer to some of those things on that strategy discussion, it’s like trying to drive a boat without a rudder.

Tom Evans | 00:44:19 – 00:46:57
Exactly.

• The second one is the outcome tree. This is a wonderful way to take what we’ve learned from the strategy discussion and customer conversations and say here are the targeted business outcomes, here are the customer or product outcomes, and now how am I going to deliver on those? How am I going to measure that we’re actually delivering that value?
• The third is framing the problem. This helps us succinctly state the customer problem that we are addressing and the value that we are delivering.
• The fourth is the outcome-based roadmap. This moves us away from a roadmap that is just a list of features and dates and toward a roadmap that starts with what are the business goals for my product, what are the key customer outcomes or product outcomes that I want to deliver, and in what order.
• And the final part is the template for thinking through the tiny acts of discovery. It helps define what we’re trying to accomplish, what our uncertainties or risks are, prioritize those, and identify hypotheses and validation methods.

All of that is in our playbook. And there’s a QR code there. It is a bargain at $25. I don’t want to sound like an infomercial, but honestly it is. And we also have a bunch of other free resources if you’re interested in those.

Productside Report, Upcoming Webinars, and Training

Kenny Kranseler | 00:46:57 – 00:50:38
So while you’re thinking up some questions to ask, here are some activities to keep you busy.

One is the report that drove this PM tension series—our product management challenges report. Use the QR code and download that report to see some of the issues that bubbled up when we asked product managers what are some of the issues they face.

And then if you’re located in Europe or London is easiest for you to get to, Tom will be doing a public class in London. I’d love to see you there. We had a fantastic cohort there last September and I’m excited to go back and do that again.

We also have upcoming webinars, including one being run by our CEO, Rina Alexin, that I’ll help moderate in a couple weeks. That one talks about how you can go from being a product manager that takes direction to one that is truly a decision maker and participates in senior discussions.

And if London isn’t practical, there are lots of other training opportunities for you, both virtual and in person. Some focus on AI and some take the full blueprint that Tom talked about earlier and give you the skills and techniques to leverage it.

Q&A and Closing Remarks

Kenny Kranseler | 00:50:38 – 00:51:44
So, we’ve got about five or six minutes or so to handle some questions.

One was: in government we often deploy scalable multi-tenant platforms, but end users later say that the CRM doesn’t match their language or workflows, after millions are spent and the system is live. What strategies actually work to recover adoption?

Tom Evans | 00:51:44 – 00:52:45
I’m going to take a guess that somebody sat down and wrote a detailed specification that said, “Here’s exactly how the CRM needs to be implemented,” and it was built according to that. What I suspect happened is that we didn’t actually sit with end users to understand what their needs were.

That gets back to the point where you’re heading straight to the spec. This is what you need to deliver. But you didn’t actually get validation or priorities around what the users were trying to accomplish.

Kenny Kranseler | 00:52:45 – 00:53:19
It goes back to your jobs-to-be-done webinar. Understand what they’re trying to get done. What does success look like for those users? Make sure the tool you’re creating or customizing aligns to those goals. Otherwise they’re not going to use it.

Tom Evans | 00:53:19 – 00:53:38
Exactly. They’ll go back to the way they always did it before. So even if the system is already live, you need to go back and understand their actual workflows and language and where the disconnect happened.

Kenny Kranseler | 00:53:38 – 00:54:17
Another question talked about the role of a product delivery lead.

Tom Evans | 00:54:17 – 00:55:44
My assumption would be that’s someone helping coordinate the actual delivery side of things—managing the organization’s readiness, dependencies, and risks. That person becomes a key stakeholder for the product manager and product owner, especially in the Create phase, helping ensure risks are identified and addressed.

Kenny Kranseler | 00:55:44 – 00:55:54
Another question: if a product organization feels chaotic right now, where should the leader start without trying to fix everything all at once?

Tom Evans | 00:55:54 – 00:57:18
I think it starts with leadership reframing the conversation around business value and customer value rather than output.

If I’m a product manager and I’m trying to push upward, saying we need to be outcome driven, but leadership is still focused only on output, then I’m not going to make progress.

The second thing is: don’t try to roll everything out to the whole organization at once. Start with a pilot. Take some of these practices and test them with one team. Learn what’s working and what isn’t, and make adjustments from there. But it has to start with that leadership narrative.

Kenny Kranseler | 00:57:18 – 00:57:52
I think the key piece is that outcome discussion template. As a product leader, use that to talk with executives and understand what’s important for the organization. Then work with your product managers so they understand the outcomes that drive business value and where their product can contribute.

Kenny Kranseler | 00:57:52 – 00:58:29
With that, we’ve hit the top of the hour. I want to thank everybody for their attention. I want to thank you, Tom, for a captivating and interesting discussion. We hope everybody found this a hugely valuable webinar. As I noted at the beginning, everybody that attended will get an email with a way to review this session if you so choose, and I encourage you to share it with others in your organization.

We really think the more exposure we have, the more value we add, the better we are for helping product managers be successful. So for that, have a great day and we will catch you in two weeks with our next webinar.

Tom Evans | 00:58:29 – 00:58:32
All right, thank you so much. Have a great rest of your day.

Kenny Kranseler | 00:58:32 – 00:58:34
All right, bye.