The B2B Podcast Index
Index
All categories
MarketingSalesSaaSFinanceHROpsLeadershipCustomer SuccessAI & DataProductStartups & FoundersRevOpsEngineering & DevTools
MethodologySubmit
Best of:MarketingSalesSaaSFinanceHROpsLeadershipCustomer SuccessAI & DataProductStartups & FoundersRevOpsEngineering & DevTools
An independent project byFame
SearchBest episodesGuestsInsightsMethodologySubmit a podcast
Index/Leadership/Service Management Leadership Podcast
Service Management Leadership Podcast artwork

Service Management Leadership - Define What Good Looks Like

Service Management Leadership Podcast · 2026-06-22 · 5 min

0:00--:--

Key moments - from our scoring

Substance score

22 / 100

Five dimensions, 20 points each

Insight Density6 / 20
Originality4 / 20
Guest Caliber4 / 20
Specificity & Evidence5 / 20
Conversational Craft3 / 20

Jeffrey Tefertiller makes a compelling case for defining success metrics and stakeholder expectations before projects go live - not weeks before. The core problem: leaders often skip early definition of what 'good' looks like, leading to mismatched expectations and wasted resources. Tefertiller advocates applying the MoSCoW requirements model (Must have, Should have, Could have, and critically, Won't include) to both requirements and outcomes, emphasizing that the 'W' - explicitly stating what will NOT be delivered - prevents stakeholders from creating their own definitions. He challenges teams using Agile, waterfall, Scrum, or SAFe to shift this conversation upstream to the requirements phase. A secondary theme addresses measurement rigor: organizations often default to easily quantifiable metrics (MTTR reduction, change success rate) while avoiding harder-to-define outcomes like 'efficiency gains.' Tefertiller warns against fuzzy estimates layered on estimates, arguing for transparent, measurable KPIs that stakeholders can actually trust. This episode is essential for project leaders, product managers, and operations heads managing expectations across waterfall and Agile delivery models.

Key takeaways

  • →Define success criteria and measurable outcomes with stakeholders at the requirements phase, not right before go-live.
  • →Use the MoSCoW model to categorize requirements (Must have, Should have, Could have) and explicitly define what will NOT be included to prevent mismatched expectations.
  • →Establish transparent, measurable metrics rather than fuzzy estimates to demonstrate progress and gain stakeholder buy-in.
  • →Identify desired improvements beyond the backlog items and measure them against clear, non-ambiguous benchmarks.
  • →Leaders must understand what good looks like from the stakeholder's perspective to provide appropriate support throughout the project.

In this episode

  1. 1Define What Good Looks Like Before Go-Live
  2. 2MoSCoW Requirements Model for Requirements and Outcomes
  3. 3Define What Will Not Be Included
  4. 4Identify Improvements and Measurable Outcomes
  5. 5Avoid Fuzzy Metrics and Ensure Transparency

Topics in this episode

MoSCoW requirements modelProject go-liveRequirements definitionMTTR reductionChange success rateAgileWaterfallScrumSAFeStakeholder expectations

Questions this episode answers

When should leaders define what good looks like for a project?

During the requirements phase, not right before go-live. Tefertiller emphasizes asking stakeholders early what good looks like and defining success metrics at project initiation rather than trying to shoehorn expectations in at the last minute.

What is the MoSCoW requirements model and how should leaders use it?

MoSCoW breaks requirements and outcomes into Must have, Should have, Could have, and Won't include (the W). The critical step most leaders miss is explicitly defining what will NOT be included or delivered, preventing stakeholders from creating their own conflicting definitions.

Why are fuzzy metrics and estimates problematic in service management?

Fuzzy numbers - estimates based on estimates based on estimates - become unreliable and lose credibility with stakeholders. Leaders should instead measure outcomes transparently through concrete KPIs like MTTR reduction and change success rate that stakeholders can verify.

How should leaders handle improvement initiatives when defining outcomes?

Define what improvements are needed and desired, not just what's already in the backlog. Pair these improvements with measurable outcomes that go beyond easy-to-track metrics to include harder-to-define benefits like efficiency gains.

What our scoring noted

Our reviewer’s read on each dimension, with quotes from the episode.

Insight Density

6 / 20

The episode makes a handful of valid but elementary points - define outcomes early, use MoSCoW, make metrics measurable - but the runtime is padded with filler and circular phrasing. No non-obvious claims surface that a working service-management professional wouldn't already know.

By fuzzy, I mean squishy. I know that helps, right?
Hopefully this resonates with you and your organization.

Originality

4 / 20

The core advice (define requirements early, use MoSCoW) is decades-old project management orthodoxy presented without any new angle, counterintuitive twist, or first-principles reasoning. There is no contrarian framing anywhere in the episode.

I'm often reminded, and you all may be as well, the old Moscow requirements model
Define the requirements and at that same time define the desired outcomes. Don't wait till you get close

Guest Caliber

4 / 20

This is a solo monologue by the host; there is no guest at all. Nothing in the transcript evidences that the host has operated at significant scale or held a senior practitioner role, and the content itself is too generic to infer deep domain authority.

My name is Jeffrey Tefertiller and I want to have a short encouragement for you leaders.
let me know how I can be of help to you or your organization.

Specificity & Evidence

5 / 20

Two concrete metrics are named (MTTR reduction, change success rate) but are dropped without any supporting data, benchmarks, or case examples. All other claims remain abstract, and no organisations, projects, or dollar figures are cited.

MTTR reduction, tangible. Change, success rate, tangible.
if I ask you to define efficiencies gained, that's a little more difficult, right?

Conversational Craft

3 / 20

The episode is an uninterrupted solo monologue with no interviewer, no follow-up questions, and no productive tension or pushback of any kind; it closes with a call-to-action for likes and subscriptions rather than deepening any idea.

I want to have a short encouragement for you leaders.
I ask that you, like, share, subscribe. Wherever you are consuming this episode

Conversation analysis

Computed from the transcript - who did the talking, and the words that came up most.

Most-used words

define13fuzzy7requirements5stakeholders4outcome4leaders3live3tangible3numbers3estimates3name2jeffrey2tefertiller2results2wait2till2

Episode notes

In this episode, Jeffrey discusses the need to define what good looks like. Email Jeffrey with any questions or feedback (jtefertiller@servicemanagement.us) Each week, Jeffrey will be sharing his knowledge on Service Delivery (Mondays) and Service Management (Thursdays). Jeffrey is the founder of Service Management Leadership, an IT consulting firm specializing in Service Management, Asset Management, CIO Advisory, and Business Continuity services. The firm's website is Jeffrey has been in the industry for 30 years and brings a practical perspective to the discussions. He is an accomplished author with seven acclaimed books in the subject area and a popular YouTube channel with approximately 1,800 videos on various topics. Also, please follow the Service Management Leadership LinkedIn page.

Full transcript

5 min

Transcribed and scored by The B2B Podcast Index.

Foreign My name is Jeffrey Tefertiller and I want to have a short encouragement for you leaders. Many times we as leaders do not define what is good. This project's going live. Are we expecting good results?

What does good look like? How is it defined? Who defines it? And so as leaders we need to take a step back, take a deep breath and understand these topics from our stakeholders perspective.

Ask them when this goes live, what does good look like to you and then we can support it appropriately. When I think about projects and initiatives, whether Agile, waterfall, scrum, safe, whatever it is, we wait till right before go live and then try to define what good is, don't you think that should be way earlier? Way, way earlier when we're doing requirements, say what does good look like? Is it secure, is it compliant, does it, what benefits are expected?

And I think about, I'm often reminded, and you all may be as well, the old Moscow requirements model or scheme where if you think of the city in Russia, Moscow, and we just use the consonants msc, W and we think about this for our requirements, what must we have and what results must we get? So requirements and outcome, what should we have as a requirement? What should we have as an outcome? Define these.

Third, what could we have as a requirement? And third, what could we have as an outcome? And then the W is one that most people get wrong. So let me say it very cleanly.

We need to define what will not be included and define for the stakeholders what will not be an outcome. If we do not define these for our stakeholders, that means that they will define them for themselves and we will have mismatched expectations. So define the requirements and at that same time define the desired outcomes. Don't wait till you get close and it's already built and then you're trying to shoehorn something in define it early.

Also you should define, think about this from an improvement model. You should define what improvements do you want, not just what's in the backlog, what improvements do we need? And when I think of measurements, and this is something that's popped up to me recently, just as I've seen it, many organizations are measuring things that are easy and then there's some in something that is very tangible. MTTR reduction, tangible.

Change, success rate, tangible. But if I ask you to define efficiencies gained, that's a little more difficult, right? It's like asking me if I've eaten healthily this last week and if you know me, the answer is usually nope, I haven't. But we, we lose sight of those things because our inputs are fuzzy.

They're fuzzy numbers. And so I want to encourage you to be thinking of when we're defining these outcomes, they have to be measurable. They can't be fuzzy metrics. They have to be measurable in a way that our stakeholders can see that we're being transparent.

The problem with fuzzy numbers, fuzzy things, estimates based upon estimates based upon estimates, is they get fuzzy. And by fuzzy, I mean squishy. I know that helps, right? But in a way where you're looking at it, you tilt your head and you're like, do I really believe this is true?

And sometimes yes, sometimes no. So we need to find ways to measure things very transparently and through numbers. Hopefully this resonates with you and your organization. My name is Jeffrey Tefertiller.

I thank you for joining us. I ask that you, like, share, subscribe. Wherever you are consuming this episode, let me know how I can be of help to you or your organization. Have an awesome day.

Bye.

Related episodes across the Index

Other episodes covering the same guests and topics, from across The B2B Podcast Index.

  • Getting Our Retrospectives Right: It's Not Just a Checkbox! With Dave WestgarthPM-Mastery · on Scrum68 / 100
  • Internal vs. External: Finding the Right Balance When Scaling Tech Teams with Wes EzzeddineSphereCast · on Agile64 / 100
  • Marketing planning in B2B: insights from experts at BESTMIX Software, Trystar, Kibo Commerce, and Digital Science | B2B Marketing Leaders PodcastB2B Marketing Leaders Podcast · on Scrum63 / 100
  • How to Improve Digital Change Collaboration: An Introduction to Service Frameworks (feat. Chris Pyatt and Victoria Banner)BA Brew · on Requirements definition60 / 100
  • Product Development with Purpose: Building a Winning Mindset and Core Principles for Success with Eric Leach, Co-founder and Chief Product Officer of Strata IdentityProduct Leaders Podcast · on Scrum51 / 100
  • Should Product Managers be Product Builders?Roman's Product Management Podcast · on Scrum50 / 100

More from Service Management Leadership Podcast

All episodes →
  • Service Management Leadership - Sticky Metrics39 / 100
  • Service Management Leadership - Ted Williams Mindset42 / 100
  • Service Management Leadership - OCM35 / 100
  • Service Management Leadership - Culture30 / 100
  • Service Management Leadership - Great AI and CMDB Demands Great Data
Explore the best B2B Leadership podcasts →
All Service Management Leadership Podcast episodes →