Ten modules, a hundred days, one page at a time. Each day gives you the
idea, a worked case file, the trap that catches people out, and the one
line to remember. Work it in order, or jump straight to what you need.
Focus: stories, ordering, acceptance, the dev team
Measured by: value delivered each increment
Horizon: sprints to releases
Project Manager
Owns The How &Amp; When
“Will we land it on time, scope and budget?”
Focus: plans, risks, dependencies, resourcing
Measured by: delivery against the plan
Horizon: start to finish of the project
Build the right thing. Build it right. Build it on time.
Day 02 / 100 · Foundations · The product lifecycle
Every product ages.
The right move at one stage is the wrong move at the next. Know which stage you're in before you choose.
Introduction
Stage 01
Prove anyone wants it.
Find product–market fit. Talk to early users daily. Change fast.
WATCH OUT FOR
Scaling before it works.
Growth
Stage 02
Win the market while it's open.
Onboarding, reliability, sales enablement, the features that unblock adoption.
WATCH OUT FOR
Drowning in feature requests from the loudest customers.
Maturity
Stage 03
Defend and extend.
Retention, efficiency, pricing, adjacent segments, fewer but bigger bets.
WATCH OUT FOR
Adding features nobody asked for to look busy.
Decline
Stage 04
Harvest, migrate or reinvent.
Protect key customers, cut cost to serve, plan the exit or the rebirth.
WATCH OUT FOR
Pretending it's still in growth.
Know your stage. Pick your moves.
Day 03 / 100 · Foundations · Outputs vs outcomes
Shipped isn’t success.
Outputs are what the team produces. Outcomes are what changes for customers because of it. Only one of them pays the bills.
Outputs
What We Make
Features and releases
Story points and velocity
Tickets closed
“It shipped on time”
Outcomes
What Changes
Customers behave differently
People stay, adopt, come back
Fewer support calls, less friction
Revenue or cost actually moves
Output
We shipped the self-service portal.
OUTCOME
Customers change their own call routing instead of phoning support.
IMPACT
Support load drops, and the team gets time back for harder work.
Ship less. Change more.
Day 04 / 100 · Foundations · Jobs-to-be-done
People hire products to get a job done.
Customers don't want your product. They want progress in their lives, and your product is one way to get there.
When [situation], I want to [motivation], so I can [expected outcome].
The Job Statement
What needs to happen?
Functional
e.g. Calls reach me wherever I am.
How do they want to feel?
Emotional
e.g. Calm. Not worried about missed sales.
How do they want to be seen?
Social
e.g. Like a real, reachable business.
Nail the job. Features follow.
Day 05 / 100 · Foundations · Problem space vs solution space
Fall in love with the problem.
Stakeholders arrive with solutions. Your job is to walk them back to the problem before anyone starts building.
Problem space
Understand First
Who has this problem?
How painful is it, and how often?
How do they cope today?
What does it cost them?
Solution space
Then Explore
What are three ways to solve it?
What's the cheapest test?
What would we prototype first?
What must be true for it to work?
01 · Discover
Go wide on the problem
02 · DEFINE
Pick the one worth solving
03 · DEVELOP
Go wide on solutions
04 · DELIVER
Build, test, ship
Problem first. Solution second.
Day 06 / 100 · Foundations · What value really means
Value lives in the customer’s eyes.
Value isn't what you put in. It's what customers get, minus everything it costs them to get it.
Value = what they gain − what it costs them
The Value Equation
Gains
What They Gain
A job done faster or better
Money made or saved
Less worry, more confidence
Looking good to their boss or customers
Costs
What They Pay
Money: price, fees, add-ons
Time: setup, learning, migration
Effort: new habits, new workflows
Risk: “what if this goes wrong?”
Raise the gain. Cut the cost.
Day 07 / 100 · Foundations · B2B vs B2C
Who pays isn’t always who uses.
Same craft, different game. Who decides, how fast, and what wins all change with the customer.
B2B · Businesses
B2C · Consumers
Who pays?
Often not the user. A buyer or committee signs.
Usually the same person who uses it.
How they decide
Business case, ROI, security, compliance.
Feel, trust, price, habit, word of mouth.
Sales cycle
Weeks to months. Many stakeholders.
Seconds to days. Often self-serve.
Feedback
A few loud accounts. Easy to over-weight.
Lots of behavioural data. Hard to hear the why.
What wins
Fits the workflow, integrates, proves return.
Delightful, simple, becomes a habit.
Win the buyer. Keep the user.
Day 08 / 100 · Foundations · The product trio
Three minds. One decision.
The best product decisions come from a PM, a designer and an engineer discovering together, not passing documents down a line.
Product Manager
Valuable &Amp; Viable
“Will they want it, and does it work for the business?”
Brings: customer, market and business context
Guards against: building the wrong thing
Product Designer
Usable
“Can people actually figure it out?”
Brings: behaviour, flows, prototypes
Guards against: confusing, unused features
Tech Lead
Feasible
“Can we build it, safely, in reasonable time?”
Brings: what's possible, cheap shortcuts, risks
Guards against: expensive or fragile builds
Discover together. Decide together.
Day 09 / 100 · Foundations · Building product sense
Product sense is a muscle.
It isn't magic taste. It's pattern recognition, built through deliberate reps with products, customers and results.
Use products critically
Tear down one product a week. What job does it do? Where does it frustrate you?
Talk to customers often
A regular rhythm of conversations beats one big research project a year.
Study what happened
After every launch, ask why it worked or didn't. Outcomes teach more than opinions.
Predict, then check
Write down what you expect before you ship. Compare later. Calibration is the skill.
Reps beat talent.
Day 10 / 100 · Foundations · Module 1 wrap-up
A PM’s week, honestly.
The job is less roadmap theatre and more constant trade-offs: between people, time and the truth about customers.
Mon
Align
Priorities for the week. Quick stakeholder check-ins.
Tue
Discover
Customer calls. Reviewing feedback and support themes.
Wed
Build
Refinement, design reviews, unblocking the team.
Thu
Decide
Data review. Trade-off calls. Saying no, kindly.
Fri
Share
Updates, demos, and what we learned this week.
Every Day
Interruptions, Slack, “quick questions”, and at least one thing nobody planned for. An example rhythm, not a rule.
Protect the time that finds the truth.
Module 2DiscoveryDays 11–20
Day 11 / 100 · Discovery · Continuous discovery habits
Discovery is a habit, not a phase.
Research done once goes stale fast. Teams that keep learning weekly make better calls, with less drama.
Discovery as a phase
The Old Way
Big research project up front
A report nobody rereads
Then months of building blind
Assumptions quietly go stale
Discovery as a habit
The Better Way
A customer conversation every week
The trio learns together
Small tests alongside delivery
Decisions updated as you learn
Talk to customers every week.
Day 12 / 100 · Discovery · Customer interviews that don't lie
Ask about the past, not the future.
People are poor predictors of their own behaviour, but reliable reporters of what they've actually done.
Hypotheticals
Questions That Mislead
“Would you use…?”
“How much would you pay for…?”
“Do you like this idea?”
“What features do you want?”
Real stories
Questions That Reveal
“Tell me about the last time…”
“What did you do next?”
“What did that cost you?”
“What have you already tried?”
Facts beat compliments.
Day 13 / 100 · Discovery · Avoiding false positives
Look for real commitment.
Compliments cost nothing. The signal you can trust is when someone gives up something to move forward.
Time
Commitment Currency 1
“Can we book a follow-up with your team?”
Signal: they give you hours, not minutes
Examples: a pilot, a workshop, real data
Reputation
Commitment Currency 2
“Who else should see this?”
Signal: they put their name on it
Examples: intro to their boss, a reference
Money
Commitment Currency 3
“Shall we start with a paid pilot?”
Signal: the strongest there is
Examples: pre-order, deposit, letter of intent
Ask for a commitment.
Day 14 / 100 · Discovery · Assumption mapping
Find the assumption that could kill it.
Every idea rests on beliefs about desirability, viability, feasibility and usability. Map them, then test the scariest one.
↑ How Important Is It? · → How Much Evidence Do We Have?
Test First
Important · little evidence
Your riskiest bets. Design an experiment this week.
Monitor
Important · strong evidence
Build on these, but keep an eye out for change.
Park
Less important · little evidence
Not worth testing yet. Revisit later.
Ignore
Less important · strong evidence
Don't spend time here.
Test the scary one first.
Day 15 / 100 · Discovery · Opportunity solution trees
Connect every idea to an outcome.
A simple map from the result you want, to customer needs, to ideas, to the tests that tell you which ideas work.
Fewer billing-related support calls
Example Tree
01 · OUTCOME
02 · OPPORTUNITIES (CUSTOMER NEEDS)
“I don't understand my invoice.”
“I can't find old invoices.”
“Extra charges surprise me.”
03 · SOLUTIONS
A plain-language invoice
Invoice history in the portal
Usage alerts by SMS
04 · EXPERIMENTS
Test a redesigned invoice with five customers
A fake-door “Download invoices” link
A two-week SMS pilot
Outcome → need → idea → test.
Day 16 / 100 · Discovery · Validate the problem first
Is the pain real?
Before testing whether people like your solution, check that the problem is frequent, painful, and already costing them.
How often?
Daily or weekly pain beats a once-a-year annoyance.
How painful?
Does it cost them money, time, customers or sleep?
Already solving it?
Workarounds and spend prove the pain is real.
Does it matter to us?
Would solving it move one of our key outcomes?
Prove the pain, then pitch the cure.
Day 17 / 100 · Discovery · Prototypes
Fake it to learn it.
A prototype is a question in disguise. Pick the cheapest one that answers the question you actually have.
The Fidelity Ladder · Climb Only When You Need To
Minutes
Sketch
Does the concept make sense to anyone?
Hours
Clickable Mockup
Can people find their way through the flow?
Days
Wizard Of Oz
Looks real, but humans do the work behind the scenes. Is it valuable?
Weeks
Concierge
Do it manually for a few customers. Will they rely on it?
Cheapest test that answers the question.
Day 18 / 100 · Discovery · Personas vs segments
Know who you’re building for.
Personas build empathy. Segments make decisions measurable. Good teams use both, grounded in real behaviour.
Personas
For Empathy
A story about a type of user
Goals, frustrations, context
Great for design conversations
Risk: invented in a workshop
Segments
For Decisions
Groups defined by shared needs
Sizable and measurable
Great for strategy and targeting
Risk: cold numbers, no story
Segment by need, not by label.
Day 19 / 100 · Discovery · Journey mapping
See the whole journey.
Customers experience your company end to end, not team by team. Map what they do and feel at each stage to find where it breaks.
Example · An Sme Switching Phone Providers
Stage 1
Discover
Hears about us
Feels: Curious
Stage 2
Buy
Compares quotes
Feels: Hopeful
Stage 3
Set up
Ports numbers
Feels: Anxious
Stage 4
Use
Makes calls daily
Feels: Fine
Stage 5
Get help
Phones support
Feels: Frustrated
Stage 6
Renew
Reviews contract
Feels: Undecided
Map reality, not the brochure.
Day 20 / 100 · Discovery · Module 2 wrap-up
“Enough” is a decision.
You'll never have perfect certainty. These signals tell you it's time to build, and keep learning while you do.
Signs You'Re Ready To Move On
Patterns repeat
New interviews stop surprising you.
Riskiest bet tested
The assumption that could kill it has evidence.
Mistakes are cheap
It's a two-way door. You can undo it.
Only usage can teach you
The next answer needs real customers using it.
Decide. Ship. Keep learning.
Module 3StrategyDays 21–30
Day 21 / 100 · Strategy · Vision, mission, strategy
Where, why and how to win.
Three words teams use interchangeably. They answer three different questions, and you need all three.
Vision
The Destination
“Where are we going?”
Horizon: years
The future you're trying to create
Mission
The Purpose
“Why do we exist, and for whom?”
Horizon: ongoing
Who you serve and why it matters
Strategy
The Choices
“What will we do, and not do?”
Horizon: 1–3 years
Where to play and how to win
Strategy is choosing.
Day 22 / 100 · Strategy · Positioning
Own a place in their mind.
Positioning is the context customers use to judge you: what you are, who you're for, and why you beat the alternative.
For [best-fit customer] who [need], [product] is a [category] that [key value]. Unlike [the alternative], we [what's truly different].
The Positioning Statement
The real alternative
Often not a competitor. It's “do nothing” or a workaround.
What's truly different
Only what you have that the alternative doesn't.
The value it creates
Why that difference matters to them.
Best-fit customers
Who cares the most about that value.
For everyone means for no one.
Day 23 / 100 · Strategy · Competitive analysis
Study rivals. Don’t copy them.
Competitors are a source of evidence about customers, not a to-do list for your roadmap.
Learn from them
Useful Questions
Which customers do they win, and why?
What job are they hired to do?
What do their customers complain about?
What can't they easily change?
Chase them
Copycat Traps
Matching their feature list
Knee-jerk price reactions
Chasing their customers, not yours
Benchmarks without context
Know them. Be you.
Day 24 / 100 · Strategy · Moats and defensibility
What stops them catching you?
Good products get copied. A moat is whatever makes your advantage last after they've copied the features.
Network effects
The product gets better as more people use it.
Switching costs
Leaving is painful: numbers, data, habits, integrations.
Unique data
Insight competitors can't easily collect.
Trust and brand
A reputation earned over years, especially in regulated work.
Scale
Costs fall as you grow, in ways small rivals can't match.
Know-how and licences
Hard-won expertise, compliance and regulatory approvals.
Features get copied. Moats compound.
Day 25 / 100 · Strategy · Build, buy or partner
Build, buy or partner?
Engineering time is your scarcest resource. Spend it only where it creates an advantage customers notice.
Build
When It Differentiates
“Is this why customers choose us?”
Gain: control and advantage
Cost: time, people, upkeep forever
Buy
When It'S A Commodity
“Does a good-enough version already exist?”
Gain: speed and focus
Cost: less control, vendor lock-in
Partner
When You Lack Reach
“Can someone else bring what we can't?”
Gain: reach and capability
Cost: shared value, dependency
Build what makes you different.
Day 26 / 100 · Strategy · Platform vs product
Products solve problems. Platforms let others do it.
A platform grows when other people build on it. That's powerful, but only once someone actually wants to.
Product
You Create The Value
You build what users need
Direct relationship with users
Grows by adding capability
Simpler to run and change
Platform
Others Create Value Too
APIs, integrations, partners
Value grows with the ecosystem
Needs docs, stability, governance
Harder to change once others depend on it
Earn the right to be a platform.
Day 27 / 100 · Strategy · Saying no strategically
Every yes is a no to something else.
Focus isn't what you choose to do. It's what you choose not to do, and saying so out loud.
Four Questions Before Any Yes
Does it serve our strategy?
If not, it's a distraction, however good the idea.
Is it for our best-fit customers?
Or for someone we've decided not to chase?
Is it the best use of the team now?
Compared with what's already on the list.
What will we stop to make room?
If the answer is “nothing”, the answer is no.
“Not now” is a strategy too.
Day 28 / 100 · Strategy · Strategy on one page
It fits on a page, or it won’t fit in heads.
If your team can't explain the strategy in a minute, it can't guide the hundred small decisions they make every week.
One-Page Template · Fictional Example
01 · WHERE WE ARE
SMEs are leaving old PBX systems, but setup feels risky.
02 · WHERE WE'RE GOING
Every small business sounds like a big one.
03 · WHERE WE'LL PLAY
Owner-run businesses, 5–50 staff, South Africa first.
04 · HOW WE'LL WIN
Same-day setup, app control, local human support.
05 · WHAT WE WON'T DO
Enterprise call centres. Custom builds for single clients.
06 · HOW WE'LL KNOW
Setup time, 90-day retention, support calls per customer.
The test: ask three people on the team what the strategy is. If you get three different answers, the page isn't done.
If the team can’t say it, it isn’t real.
Day 29 / 100 · Strategy · OKRs that don't rot
Objectives inspire. Key results prove.
OKRs work when they measure outcomes and get checked every week. Set-and-forget OKRs are just quarterly wishes.
Set and forget
Okrs That Rot
Outputs as key results
Too many objectives
Reviewed only at quarter end
Tied to bonuses, so targets go soft
Checked weekly
Okrs That Live
Outcomes as key results
Three objectives at most
A weekly confidence check
Honest grading, then learning
Objective: Customers manage their own phone system with confidence
Example
Weak KR: Launch the self-service portal.
Strong KR: A set share of routing changes happen through self-service, not support calls.
Few goals. Checked weekly.
Day 30 / 100 · Strategy · Module 3 wrap-up
Plans break. Strategy adapts.
A strategy is a bet based on assumptions. When the evidence changes, the bet should too, on purpose, not by drift.
Signals It'S Time To Revisit
The market shifts
New entrants, new tech, new customer expectations.
A core assumption breaks
Evidence contradicts something the strategy relies on.
New capabilities appear
Something that was impossible is suddenly cheap.
Repeated misses
The same goals keep failing for the same reasons.
Hold the vision. Flex the path.
Module 4PrioritisationDays 31–40
Day 31 / 100 · Prioritisation · RICE and its blind spots
A score is a conversation, not a verdict.
RICE makes trade-offs visible and comparable. It's a great way to argue well, and a poor substitute for judgement.
(Reach × Impact × Confidence) ÷ Effort
The Formula
Reach
How many people it affects in a set period.
Impact
How much it moves the outcome for each of them.
Confidence
How sure you are, based on evidence, not hope.
Effort
Person-time to build, test and ship it.
Score to debate, not to decide.
Day 32 / 100 · Prioritisation · Cost of delay
What does waiting cost?
Value isn't the only question. Some work loses value every week it waits; some becomes worthless after a date.
Cost of delay ÷ Duration
Cd3: What To Do First
Expedite
Big cost right now. Incidents, security holes.
Fixed date
Worthless or penalised after a deadline. Regulation, events.
Standard
Value lost steadily for every week it waits.
Intangible
Little cost today, big cost later. Tech debt, skills.
Ask what waiting costs, not just what it’s worth.
Day 33 / 100 · Prioritisation · The Kano model
Not every feature delights.
Customers react to features in different ways. Some are only noticed when missing; some make people smile.
Basics
Expected
“It just has to work.”
If missing: angry customers
Example: calls connect clearly
Performance
More Is Better
“The better it is, the happier I am.”
If improved: more satisfaction
Example: call quality, fair pricing
Delighters
Unexpected
“Oh, that's clever!”
If missing: nobody notices
Example: voicemails transcribed to email
Watch out: today's delighter becomes tomorrow's basic. What surprised customers five years ago is now expected.
Fix the basics. Then delight.
Day 34 / 100 · Prioritisation · Now / Next / Later
Roadmaps without fake dates.
Confidence drops the further out you look. A good roadmap is honest about that instead of hiding it behind dates.
Now
Committed · High Confidence
Self-service call routing
Faster number porting
Next
Shaped · Medium Confidence
Clearer invoices
After-hours call handling
Later
Exploring · Low Confidence
“Owners miss calls on the road”
“Teams can't see call trends”
Commit to the near. Flex on the far.
Day 35 / 100 · Prioritisation · Outcome roadmaps
Roadmap the problems, not the features.
Feature lists lock in solutions before you've learned anything. Outcome roadmaps commit to results and leave room for the best answer.
Feature list
Locks In Solutions
Q1: Mobile app
Q2: Chatbot
Q3: Analytics dashboard
Success = it shipped
Outcome roadmap
Commits To Results
Q1: Cut setup time
Q2: Fewer billing support calls
Q3: Better 90-day retention
Success = the number moved
Promise outcomes. Discover features.
Day 36 / 100 · Prioritisation · Managing the HiPPO
When the boss has an idea.
The Highest-Paid Person's Opinion often carries real context. Treat it as a hypothesis worth testing, not an order or a threat.
Four Moves
Get curious
What problem are they seeing that we might be missing?
Frame it as a hypothesis
“If we do X, we expect Y to change.”
Propose a cheap test
The smallest experiment that would teach us something.
Agree on the evidence
What result would change either of our minds?
Respect the idea. Test the idea.
Day 37 / 100 · Prioritisation · Tech debt as a product decision
Tech debt is a product problem.
Debt slows every feature and raises the risk of every release. That makes it a trade-off for product, not a hobby for engineers.
Deliberate
A Conscious Shortcut
“We'll fix it after launch.”
OK when: there's a plan to repay it
Risk: “after launch” never comes
Accidental
We Learned Better
“We'd design it differently now.”
OK when: it's blocking real work
Risk: endless rewrites
Bit rot
The World Moved On
“That framework is out of support.”
OK when: never; it only grows
Risk: security and outages
Debt has interest. Pay it on purpose.
Day 38 / 100 · Prioritisation · Opportunity scoring
Find needs that are important and underserved.
Ask customers two questions about each need: how important is it, and how satisfied are you today? The gap is your opportunity.
Importance + (Importance − Satisfaction)
The Formula
13
CUSTOMER NEED · FICTIONAL EXAMPLE (1–10)
IMPORTANCE
SATISFACTION
OPPORTUNITY
Calls reach me wherever I am
9
5
I understand my invoice
8
4
12
Detailed call analytics
5
6
5
Underserved
High importance, low satisfaction. Invest here.
Overserved
Low importance, high satisfaction. Simplify, or charge less.
Important + unhappy = opportunity.
Day 39 / 100 · Prioritisation · The roadmap as communication
One roadmap, many audiences.
A roadmap's real job is alignment. Different people need different levels of detail and certainty from the same plan.
Executives
Why &Amp; Outcomes
“How does this move the business?”
Show: strategy fit, outcomes, big bets
Skip: ticket-level detail
Sales & customers
What'S Coming
“What can I tell my client?”
Show: themes and broad timing
Skip: exact dates and internal debates
Delivery team
What'S Next &Amp; Why
“What are we building, and why now?”
Show: priorities, detail, dependencies
Skip: nothing important
Same plan. Different story.
Day 40 / 100 · Prioritisation · Module 4 wrap-up
Stopping is a skill.
Good teams kill work that isn't working, openly and early, so the time goes to something that might.
How To Stop Well
Agree kill criteria up front
Decide what result would make you stop, before you start.
Show the evidence
Make it about the data, not about anyone's idea.
Name what was learned
Thank the team. Record the lesson. It wasn't wasted.
Redirect visibly
Tell stakeholders early, and show where the capacity goes.
Kill it clearly. Keep the lessons.
Module 5MetricsDays 41–50
Day 41 / 100 · Metrics · North Star metrics
One number that means customers win.
A North Star metric captures the value customers get from your product. When it grows, the business should follow.
A Good North Star…
Reflects customer value
It goes up when customers genuinely get what they came for.
Predicts business results
Revenue and retention tend to follow it.
Can be influenced
Teams can see how their work moves it.
Moves often enough
Weekly, not once a year, so you can learn from it.
One star. Many paths to it.
Day 42 / 100 · Metrics · Input vs output metrics
You can’t move outputs directly.
Outputs tell you whether you're winning. Inputs are the levers your team can actually pull this week.
Output metrics
Results · Slow · Hard To Act On
Revenue
Retention
Customer satisfaction
Market share
Input metrics
Actions · Fast · Within Your Control
Setups completed within a day
Support response time
New feature adoption
Number porting success rate
Manage inputs. Watch outputs.
Day 43 / 100 · Metrics · Funnels
Find where people leak.
A funnel shows each step between interest and value, and how many people make it through. The biggest drop is your first question.
100%
Fictional Sign-Up Funnel
Visit the website
Start sign-up
30%
Complete sign-up
18%
Port their number
10%
Make a first call
9%
Fix the leak before adding water.
Day 44 / 100 · Metrics · Cohorts and retention curves
Group users by when they joined.
A cohort is everyone who started in the same week or month. Following each group over time shows whether the product is really getting better.
Falls to zero
Nobody sticks. Fix the product before growth.
Flattens
A core group keeps using it. A sign of fit.
Smiles
Users come back and grow. The best shape.
Averages hide. Cohorts reveal.
Day 45 / 100 · Metrics · Activation
Find the aha moment.
Activation is the earliest action that predicts a customer will stick around. Get more people there, sooner.
How To Find It
1 · List candidate actions
First call, first voicemail, first app login, first routing rule.
2 · Compare groups
What did customers who stayed do early that leavers didn't?
3 · Set the threshold
The action, plus how many times, within how many days.
4 · Design onboarding for it
Remove every step that doesn't lead there.
Get them to value, fast.
Day 46 / 100 · Metrics · Vanity metrics
Numbers that feel good and change nothing.
If a number always goes up and never changes a decision, it's there to make you feel good, not to help you steer.
Vanity metrics
Feel Good
Total registered users
Page views
App downloads
Features shipped
Actionable metrics
Drive Decisions
Active users, by cohort
Conversion at each step
Retention over time
Time to first value
The test:
if this number changed tomorrow, what would we do differently? If the answer is “nothing”, it's vanity.
If it can’t change a decision, it’s decoration.
Day 47 / 100 · Metrics · Guardrail metrics
Win without breaking something.
Every change that improves one metric can quietly harm another. Guardrails are the numbers you promise not to damage.
Primary metric ↑ while guardrails hold
The Pairing
Customer satisfaction
Are people happier, or just faster?
Errors and incidents
Did we introduce instability?
Support contacts
Did we move work onto the support team?
Revenue quality
Did we attract customers who won't pay?
Move the needle. Mind the fences.
Day 48 / 100 · Metrics · Leading vs lagging indicators
See it coming.
Lagging indicators confirm what already happened. Leading indicators give you time to change the outcome.
Lagging
Confirms · Slow
Churn
Revenue
Annual satisfaction scores
Contract renewals
Leading
Predicts · Actionable
Falling weekly usage
Rising support tickets
Logins dropping off
Key features going unused
Lagging tells you. Leading warns you.
Day 49 / 100 · Metrics · Goodhart's Law in practice
When a measure becomes a target…
…it stops being a good measure. People optimise the number, and the thing it was meant to represent quietly suffers.
How It Shows Up
Tickets closed
Tickets get closed before problems are solved.
Velocity
Story points quietly inflate.
Calls made
More calls, lower quality.
AI acceptance rate
People approve outputs without checking them.
Measure the goal, not the game.
Day 50 / 100 · Metrics · Module 5 wrap-up
Connect every metric to the top.
A metrics tree links the North Star to the drivers behind it and the inputs each team owns. Everyone can see how their work counts.
Businesses making successful calls every week
Example Metrics Tree
NORTH STAR
DRIVERS
New businesses activated
Calls per business per week
Businesses still active at 90 days
INPUTS TEAMS CAN MOVE
Setup time and porting success
App adoption and call routing use
Support resolution and call quality
OWNERS
Onboarding squad
Product squad
Support and network ops
Every metric should ladder up.
Module 6EvidenceDays 51–60
Day 51 / 100 · Evidence · Writing a good hypothesis
Turn opinions into testable bets.
A hypothesis states what you'll change, for whom, what you expect, and how you'll know. Most importantly, it can be proven wrong.
We believe [this change] for [these customers] will [produce this outcome]. We'll know we're right when [this metric moves this much, by this date].
The Template
If it can’t fail, it isn’t a test.
Day 52 / 100 · Evidence · A/B testing basics
Let customers vote with their behaviour.
An A/B test shows two versions to similar groups at the same time. Randomisation is what lets you say the change caused the difference.
01 · Split
Randomly assign users to A (today) or B (the change).
02 · CHANGE ONE THING
So you know what caused any difference.
03 · MEASURE
The primary metric, plus guardrails.
04 · WAIT, THEN DECIDE
Run for the agreed time. No peeking early.
Version A
Control
What customers see today
The baseline you compare against
Version B
Variant
One deliberate change
Everything else identical
Randomise. Wait. Then decide.
Day 53 / 100 · Evidence · Sample size and significance, simply
Is it real, or just noise?
Results bounce around by chance. Statistics helps you tell a real difference from a lucky streak.
The Coin-Flip Intuition
Flip a fair coin 10 times and get 7 heads? Not surprising. Flip it 1,000 times and get 700? Something's going on. More data makes chance easier to rule out.
Sample size
Small samples swing wildly. Plan the size before you start.
Significance
How unlikely the result would be if nothing had really changed.
Effect size
How big the difference is. Small effects need big samples.
Duration
Run whole weeks, so weekday and weekend behaviour both count.
Small samples tell tall tales.
Day 54 / 100 · Evidence · When not to A/B test
Not every question needs an experiment.
A/B tests are powerful but narrow. Sometimes another method gets you a better answer, faster and more safely.
Skip The A/B Test When…
There's too little traffic
You'd wait months for a trustworthy answer.
It's unfair or unsafe
Different prices or protections for similar customers.
The fix is obvious
A broken button doesn't need a test. Fix it.
Effects take months
Trust and brand don't show up in a two-week test.
Right question, right method.
Day 55 / 100 · Evidence · Kill criteria
Decide when to stop before you start.
Once you've invested, it's hard to be objective. Kill criteria written up front make the tough call easier later.
Four Parts Of A Kill Criterion
The metric
The one number that shows it's working.
The threshold
The level below which you stop.
The timebox
How long you'll give it before deciding.
The decider
Who makes the call, so it isn't argued forever.
“If fewer than one in five pilot customers use chat weekly after six weeks, the product lead stops the project.”
Example · In-App Support Chat
Write the exit before the entrance.
Day 56 / 100 · Evidence · Root cause analysis
Keep asking why.
The first explanation is usually a symptom. Keep asking why until you reach something the team can fix for good.
Five Whys · Fictional Example
The Problem
New customers are leaving within 60 days.
Why?
Their number porting took weeks, not days.
Why?
Every port request is checked by hand.
Why?
There's no automated validation of port forms.
Root Cause
Nobody owns the porting experience end to end.
The fix: give porting an owner and a target, and automate the checks. Faster ports follow.
Fix the system, not the symptom.
Day 57 / 100 · Evidence · Survivorship and selection bias
Who’s missing from your data?
The customers you can easily hear from are rarely typical. The ones who leave, or never start, are often the most important.
Survivorship bias
Only Studying Who Stayed
Churned customers don't answer your survey
Winning features get studied; failures are forgotten
“Our best customers love it” hides who left
Selection bias
Hearing From The Wrong Few
The loudest customers set the agenda
Beta volunteers are unusually keen
Survey responders differ from everyone else
Listen for the silence.
Day 58 / 100 · Evidence · Qual + quant together
Numbers say what. People say why.
Data at scale shows patterns but not reasons. Conversations show reasons but not scale. You need both.
Quantitative
Scale · Blind To Reasons
What happened, how often
Across every customer
Trends and comparisons
Qualitative
Depth · Small Samples
Why it happened
How it feels
The context around it
Quant Spots
Something changed, and where.
QUAL EXPLAINS
Why it changed, in customers' own words.
QUANT CONFIRMS
Whether the fix worked at scale.
Spot with numbers. Understand with people.
Day 59 / 100 · Evidence · Fake doors and painted doors
Measure demand before you build.
Put the entrance to a feature in front of customers before the feature exists, and count who tries to walk through.
How it works
A button, menu item or plan option for something not yet built.
What it measures
Real interest, from real customers, in context.
Be honest right away
After the click: “Coming soon. Want early access?”
Keep it short
Days or weeks, not months. Then decide.
Never for: billing, security, or anything where a fake option could cause real harm or confusion.
Test interest with honesty.
Day 60 / 100 · Evidence · Module 6 wrap-up
Question the data before you trust it.
Most data you'll use was collected by someone else, for another purpose. Know its quirks before you make decisions with it.
Four Questions For Any Dataset
Where did it come from?
Which system, collected how, and by whom?
What does each field mean?
“Active” and “customer” mean different things to different teams.
What's missing?
Excluded accounts, failed events, test data mixed in.
What changed over time?
New tracking, new definitions, migrations.
Trust, but verify the pipeline.
Module 7EngineeringDays 61–70
Day 61 / 100 · Engineering · Writing specs
Write specs people actually read.
A spec's job is shared understanding, not completeness. One clear page that stays current beats thirty that nobody opens.
The One-Page Spec
01 · PROBLEM & WHO
What's broken, for which customers, and how we know.
02 · OUTCOME & METRIC
What changes if we succeed, and how we'll measure it.
03 · SCOPE
What's in. Just as important: what's out.
04 · KEY FLOWS
The main journeys, sketched. Link to designs.
05 · OPEN QUESTIONS
What we don't know yet, and who's finding out.
06 · RISKS & DEPENDENCIES
Compliance, other teams, vendors, deadlines.
Write it for the engineer who joins the team next month and needs to understand why, not just what.
Short, living, and clear on why.
Day 62 / 100 · Engineering · Acceptance criteria that bite
Define done before you build.
Good acceptance criteria are specific enough that a developer, a tester and a customer would all agree on whether they're met.
Given · When · Then
Given a customer is logged into the portal, When they request a voicemail PIN reset, Then a new PIN arrives by SMS within a minute, and the old PIN stops working.
Testable
A clear yes or no. No “should work well”.
Specific
Numbers, states and messages, not adjectives.
Covers the unhappy path
Wrong number? Expired session? SMS fails?
Written together
PM, developer and tester agree before building.
If you can’t test it, it isn’t done.
Day 63 / 100 · Engineering · Slicing
Ship the thinnest slice that works.
Slice work vertically, through every layer, so each piece is something a customer can actually use.
A Vertical Slice Cuts Through All Layers
INTERFACE
BUSINESS LOGIC
DATA
The green column is usable on its own. Building one whole grey row first gives customers nothing.
Thin slices. Real value. Often.
Day 64 / 100 · Engineering · Architecture choices PMs should care about
Some tech decisions are product decisions.
You don't need to design the system. You do need to spot the choices that will shape what the product can do for years.
Ask About These
The data model
It decides what you can report on and personalise later.
Where data lives
Location affects compliance, cost and trust.
Integrations
What connects easily now, and what never will.
One-way doors
Choices that are costly or impossible to undo.
Ask about the one-way doors.
Day 65 / 100 · Engineering · Non-functional requirements
How well, not just what.
Features describe what the product does. Non-functional requirements describe how well it has to do it, and they're easy to forget.
Performance
How fast is fast enough, for which users?
Reliability
What uptime do customers need? What happens when it fails?
Security
Who can see and do what? How is it attacked?
Privacy & compliance
What personal data is stored, where, and for how long?
Accessibility
Can everyone use it, including with assistive tech?
Scalability
What happens at ten times today's customers?
Quality is a requirement.
Day 66 / 100 · Engineering · Feature flags and gradual rollouts
Release to some before you release to all.
Feature flags separate deploying code from releasing features. You can switch things on for a few customers, watch, and switch off instantly.
Internal
Your own team first.
A FEW %
A small group of real customers.
A QUARTER
Watch guardrails closely.
HALF
Confidence is growing.
EVERYONE
Then remove the flag.
Instant off switch
No emergency release needed if it goes wrong.
Real-world testing
Learn from real customers, with limited risk.
Deploy any time
Code ships continuously; features launch on purpose.
Clean up
Remove flags once rolled out, or they pile up.
Deploy anytime. Release on purpose.
Day 67 / 100 · Engineering · Incident thinking for PMs
When it breaks, what’s your job?
You won't be fixing the servers. Your job is to keep customers informed, protect the team's focus, and make sure lessons turn into action.
Communicate
During The Incident
Keep customers and stakeholders updated
Shield engineers from interruptions
Pause risky releases
Make trade-off calls quickly
Follow through
After The Incident
Join the blameless postmortem
Turn actions into prioritised work
Tell customers what changed
Track whether it happens again
Calm comms. Real follow-through.
Day 68 / 100 · Engineering · APIs as products
Developers are users too.
If other businesses build on your API, it's a product. Its users are developers, and their experience decides whether they succeed.
Clear docs
Accurate, with examples. Updated with every change.
Stable versions
Changes announced early. Old versions retired gently.
Helpful errors
Messages that say what went wrong and how to fix it.
Fast first success
A sandbox and a quick-start. Measure time to first working call.
Treat your API like a product.
Day 69 / 100 · Engineering · Working with Ops and support
The front line knows first.
Support and operations hear about problems long before dashboards do. Build them into how you discover, launch and learn.
Invite them into discovery
They know the real pain points, and the workarounds.
Brief them before launch
Release notes, FAQs and known issues, in advance.
Build a feedback loop
Tag tickets by feature. Review the top themes weekly.
Measure support impact
Did the launch create or remove support work?
Launch with them, not at them.
Day 70 / 100 · Engineering · Module 7 wrap-up
Speak both languages.
Tech debt debates go wrong when engineers talk about code and product talks about features. Translate both into customer and business impact.
ENGINEERS SAY
WHAT IT MEANS FOR THE PRODUCT
“The billing code is a mess.”
Billing changes are slow and risky.
“The framework is end-of-life.”
No more security patches from here on.
“Our tests are flaky.”
Releases slip, and bugs reach customers.
“We need to refactor this module.”
Features in this area will keep getting slower.
Same team. Same outcomes.
Module 8LaunchDays 71–80
Day 71 / 100 · Launch · Go-to-market basics
Building it is half the job.
Go-to-market is how the right customers hear about it, understand it, buy it and get help. Plan it alongside the build, not after.
Six Go-To-Market Questions
01 · WHO
Which best-fit customers is this for first?
02 · WHAT
What's the value, in their words, in one sentence?
03 · WHERE
Which channels actually reach them?
04 · HOW
Pricing, packaging and how they'll buy it.
05 · WHEN
Timing, and how big a launch it deserves.
06 · WHO HELPS
Sales, support and partners, briefed and ready.
Plan the launch while you build.
Day 72 / 100 · Launch · Launch tiers
Not every launch needs a parade.
Sort launches by impact, then match the effort. Big news gets a big launch; small improvements get a quiet, useful note.
Tier 1
Major
New product, new plan, big shift.
Effort: campaign, sales training, exec voice
Lead time: weeks
Tier 2
Notable
A meaningful new capability.
Effort: email, in-app, support briefing
Lead time: days
Tier 3
Minor
Improvements and fixes.
Effort: release notes, in-app tip
Lead time: same day
Match the noise to the news.
Day 73 / 100 · Launch · Onboarding design
The first week decides everything.
Onboarding isn't a tour of features. It's the shortest path from sign-up to the moment a customer gets real value.
Lead to the aha moment
Every step should move toward the action that predicts retention.
Remove steps
Each extra screen is a place to drop off. Defer anything optional.
Show progress
A simple checklist tells people how close they are.
Add humans where it's scary
Offer help at high-risk moments, like porting a number.
Value first. Features later.
Day 74 / 100 · Launch · Switching costs
Better isn’t enough.
Customers compare your product with the cost of changing, not just with their current tool. Lower that cost and better can finally win.
Money
Exit fees, new hardware, overlapping contracts.
Time
Setup, migration, retraining staff.
Risk
Downtime, lost numbers, “what if it fails?”
Habit
Familiar workflows and relationships.
Lower the wall they have to climb.
Day 75 / 100 · Launch · Pricing fundamentals
Price the value, not the cost.
Your costs set the floor and competitors set expectations, but the value customers get is what decides what they'll pay.
Cost-plus
Cost + Margin
“What does it cost us?”
Upside: simple
Downside: ignores value entirely
Competitor-based
Match The Market
“What do others charge?”
Upside: feels safe
Downside: a race to the bottom
Value-based
Share Of Value
“What is it worth to them?”
Upside: fair and sustainable
Downside: needs real customer insight
Price reflects value delivered.
Day 76 / 100 · Launch · Packaging and plans
Good plans make choosing easy.
Packaging decides which features go in which plan. Done well, each customer instantly sees the plan that's for them, and why they'd upgrade.
Fictional Example · Good, Better, Best
Starter
For owners who just need calls to reach them.
✓
Business number
✓
Calls to your mobile
✓
Voicemail to email
Business
For teams sharing the phones.
✓
Everything in Starter
✓
Ring groups and hours
✓
Call history and reports
Compliance
For regulated businesses.
✓
Everything in Business
✓
Call recording
✓
Audit trail and retention
One plan per segment
Each plan maps to a distinct kind of customer.
A clear reason to upgrade
The next plan solves the next problem they'll hit.
Three clear choices beat twelve clever ones.
Day 77 / 100 · Launch · Adoption vs awareness
They know about it. Why don’t they use it?
An announcement creates awareness. Adoption only happens when the feature shows up at the moment someone needs it.
Aware
They know it exists.
TRIED
They used it once.
REPEATED
They came back.
HABIT
It's part of how they work.
Not relevant to them
Announced to everyone, useful to a few.
Hard to find
Buried three menus deep.
Value isn't clear
They don't see what's in it for them.
The first try disappointed
One bad experience, and they don't come back.
Announced isn’t adopted.
Day 78 / 100 · Launch · Release notes people read
Write about them, not you.
Customers don't care what you changed. They care what's better for them now, and whether they need to do anything.
Engineer-speak
Written For Us
“Refactored routing engine with async processing.”
“Resolved issue #4812.”
“Various performance improvements.”
Customer-speak
Written For Them
“Calls to your mobile now connect faster.”
“Voicemail emails no longer land in spam.”
“Your call history loads much quicker.”
Benefit first
Lead with what's better, not what changed.
Plain language
No jargon, ticket numbers or code names.
Show it
A screenshot or short clip beats a paragraph.
Say what to do
Any action needed? Say so clearly, up front.
Lead with what’s better for them.
Day 79 / 100 · Launch · Sales enablement
Sales can’t sell what they don’t understand.
Give Sales a simple, honest kit early, and keep listening to what they hear from customers.
The Enablement Kit
01 · THE ONE-LINER
What it is and why it matters, in one sentence.
02 · WHO IT'S FOR
And, just as clearly, who it isn't for.
03 · OBJECTIONS
The top five pushbacks, with honest answers.
04 · THE DEMO
A short script that shows the value, not every button.
05 · PRICING
Plans, discounts, and where the limits are.
06 · WHAT NOT TO PROMISE
What's not built yet, and roadmap rules.
Enable early. Listen always.
Day 80 / 100 · Launch · Module 8 wrap-up
Did it work?
Launch day is when learning starts. Book reviews at 30, 60 and 90 days, and decide what happens next.
Day 30
Is anyone using it? Any surprises or problems?
DAY 60
Are they coming back? Is support load changing?
DAY 90
Did the outcome move? Iterate, scale or stop?
Did adoption hit target?
Compared with what we agreed before launch.
Did the outcome move?
The reason we built it in the first place.
What surprised us?
Unexpected users, uses, or problems.
What next?
Iterate, scale, or kill. Decide, don't drift.
Launch is the start of learning.
Module 9StakeholdersDays 81–90
Day 81 / 100 · Stakeholders · Influence without authority
Lead without the title.
PMs rarely manage the people they need. Influence comes from trust, evidence and making it easy for others to say yes.
Evidence
Customer stories and data beat opinions, including yours.
Relationships
Trust built before you need it, not in the crisis.
Clarity
A crisp problem statement makes alignment easy.
Shared goals
Connect your ask to what they already care about.
Earn trust before you need it.
Day 82 / 100 · Stakeholders · Stakeholder mapping
Know who matters, and how.
Map stakeholders by how much power they have over the work and how interested they are in it. Then engage each group differently.
↑ Power · → Interest
Keep Satisfied
High power · lower interest
Short, occasional updates. No surprises.
Manage Closely
High power · high interest
Involve early and often. Co-create.
Monitor
Lower power · lower interest
Light touch. Check in now and then.
Keep Informed
Lower power · high interest
Regular updates. Invite their input.
Map them before they surprise you.
Day 83 / 100 · Stakeholders · RACI vs RAPID
Who decides?
Two popular frameworks for clarifying roles. RACI is built for getting work done; RAPID is built for making decisions.
RACI
For Tasks &Amp; Execution
Responsible: does the work
Accountable: owns the result
Consulted: gives input
Informed: kept up to date
RAPID
For Decisions
Recommend: proposes the option
Agree: must sign off (e.g. Legal)
Perform · Input
Decide: makes the final call
One decider. Everyone knows who.
Day 84 / 100 · Stakeholders · Saying no to executives
No, but here’s what we can do.
A flat no rarely works with executives. Making the trade-off visible, then offering options, usually does.
Four Steps
1 · Acknowledge the goal
Show you understand what they're trying to achieve.
2 · Show the trade-off
What would slip if we said yes? Be specific.
3 · Offer options
A smaller version, a later date, or a swap.
4 · Let them choose
With the trade-offs clear, it's their call to make.
Make the trade-off visible. Let them choose.
Day 85 / 100 · Stakeholders · Working with Legal and compliance
Bring Legal in early.
Legal says no to things they see late and don't understand. Brought in early, they help shape products that are both compliant and good.
Involve them in discovery
Share the problem while the solution is still open.
Explain the why
Context helps them find a safe way to yes.
Ask “how can we do this safely?”
Not “can we do this?”, which invites a no.
Record decisions
Impact assessments and sign-offs, kept with the product docs.
Partners early. Not gatekeepers late.
Day 86 / 100 · Stakeholders · Running a great review meeting
Every meeting needs a decision.
A review meeting exists to decide something. If there's nothing to decide, send an update instead.
Before
Send a short pre-read with the question to answer.
START
State the decision needed, in one sentence.
MIDDLE
Discuss options and evidence, not status.
END
The decision, the owner, the next step.
Only the right people
Deciders and key inputs. Everyone else gets the notes.
Shorter than you think
Most decisions need 30 minutes with a good pre-read.
Write it down
Decisions recorded where everyone can find them.
Close the loop
Share the outcome with everyone affected.
No decision? No meeting.
Day 87 / 100 · Stakeholders · Writing for decisions: the memo
Write it down to think it through.
Writing a short memo forces clear reasoning. Reading it together at the start of a meeting means everyone starts from the same facts.
The Decision Memo
01 · CONTEXT
What's happening, in a few sentences.
02 · PROBLEM
What's broken, for whom, and the evidence.
03 · OPTIONS
Two or three real options, with the trade-offs.
04 · RECOMMENDATION
Which option, and why. Be clear.
05 · RISKS
What could go wrong, and how we'd handle it.
06 · DECISION NEEDED
From whom, and by when.
Try this: start the meeting with ten minutes of silent reading. Discussion gets sharper, and the quietest people have read the same facts as the loudest.
Clear writing is clear thinking.
Day 88 / 100 · Stakeholders · Handling conflict between teams
Conflict is about goals, not people.
Most cross-team conflict comes from different goals and pressures. Make those visible and the argument usually changes shape.
Name the shared goal
What do both teams ultimately want for the customer?
Surface constraints
What pressures and targets is each team under?
Positions vs interests
“We need X” hides a reason. Find the reason.
Agree criteria, then decide
Decide how to choose before choosing.
Separate the people from the problem.
Day 89 / 100 · Stakeholders · Managing up
Make your boss’s job easier.
Managing up isn't flattery. It's keeping your manager informed, aligned and able to support you when it counts.
No surprises
Bad news travels best early, and from you.
Problems with options
Bring the issue, plus two ways forward.
Know their goals
What are they measured on? What keeps them up at night?
Match their style
Short summary first. Detail when asked.
No surprises. Bring options.
Day 90 / 100 · Stakeholders · Module 9 wrap-up
Grow people, not just products.
The best product leaders multiply themselves. Give people bigger problems, real ownership, and coaching along the way.
Associate Pm
Learns the craft. Owns well-defined features.
PRODUCT MANAGER
Owns a problem area and its outcomes.
SENIOR PM
Shapes strategy for a product area. Coaches others.
PRODUCT LEAD
Sets direction. Grows the PMs around them.
Give outcomes, not tasks
Ownership of a result builds judgement faster than a to-do list.
Coach with questions
“What options did you consider?” beats giving the answer.
Share context
Strategy, politics, trade-offs. Let them see the bigger picture.
Feedback often
Small, specific, frequent. Not once a year.
Your product is also your people.
Module 10AI featuresDays 91–100
Day 91 / 100 · AI features · When AI is the right answer
Use AI where uncertainty is OK.
AI is great with language, patterns and judgement calls that a person can check. It's a poor choice when answers must be exact every time.
Use AI
Good Fit
Summarising, drafting, classifying
High volume, repetitive judgement
A person can review the output
“Mostly right” still helps
Use rules and code
Poor Fit
Exact answers required, like billing
Simple rules already work
High stakes with no review
No good data to ground it
Right tool. Not the shiny tool.
Day 92 / 100 · AI features · Designing for wrong answers
AI will be wrong. Plan for it.
Every AI feature produces some wrong answers. Good products make them easy to spot, cheap to fix and safe when they slip through.
Make errors visible
Show sources, so people can check claims quickly.
Make errors easy to fix
Edit, regenerate, undo. One click, not a support ticket.
Limit the blast radius
Drafts for review, not automatic sends.
Learn from corrections
Every fix feeds back into testing and improvement.
Design the failure before it happens.
Day 93 / 100 · AI features · AI UX patterns
Good AI feels like a helpful colleague.
The best AI features fit into work people already do. These patterns keep people in control while AI takes the grunt work.
Six Patterns That Work
01 · DRAFT, THEN EDIT
AI writes the first version. The person finishes it.
02 · SUGGEST, DON'T ACT
Offer the next step. Let the person confirm.
03 · SHOW THE SOURCES
Every claim links back to where it came from.
04 · HELP IN CONTEXT
Appear inside the workflow, not in a separate chat.
05 · EASY UNDO
Any AI action can be reversed instantly.
06 · CLEAR HUMAN HANDOFF
A visible, easy way to reach a person.
Assist the work. Don’t hijack it.
Day 94 / 100 · AI features · Evals as product metrics
Test AI like you test code.
An eval is a set of real examples with a clear definition of “good”, run every time something changes. It's how you know quality, instead of guessing.
Collect
Real examples from real use.
DEFINE GOOD
A simple rubric for what a great answer looks like.
SCORE
People and automated checks.
RUN ON CHANGE
New prompt, model or data? Re-run.
TRACK
Watch scores over time.
Accuracy
Is it right?
Groundedness
Is it supported by the sources?
Helpfulness
Does it actually help the person?
Harm rate
Anything unsafe, private or embarrassing?
No evals, no confidence.
Day 95 / 100 · AI features · Cost per successful outcome
Measure cost per success, not per call.
The cheapest model per request can be the most expensive per result, once you count failures, retries and human clean-up.
Total AI + human cost ÷ Successful outcomes
The Real Cost
Model choice
Bigger models cost more per call and may fail less.
Context length
Long prompts and documents add up quickly.
Retries and failures
Every failed attempt is paid for.
Human review time
Often the biggest cost of all.
Cheap per call can be expensive per result.
Day 96 / 100 · AI features · Human-in-the-loop design
Decide where humans stay in charge.
How much AI should do on its own depends on the cost of a mistake. Match autonomy to risk, one decision at a time.
Ai Suggests
The person decides and acts.
PERSON APPROVES
AI acts after a yes.
AI ACTS, PERSON REVIEWS
Checked after the fact.
AI ACTS ALONE
Only where mistakes are cheap and reversible.
Impact of an error
Who is harmed, and how badly?
Reversibility
Can it be undone quickly and completely?
Regulation
Do rules require a human decision here?
Real review
Does the reviewer have the time and info to check?
Match autonomy to risk.
Day 97 / 100 · AI features · Trust and transparency
Tell people when it’s AI.
People accept AI much more readily when they know it's there, understand its limits and can always reach a human.
Disclose it
Make it clear when people are dealing with AI.
Show why
Where the answer came from, in plain language.
Set expectations
Say what it can't do, before it disappoints.
Give control
Edit it, turn it off, or reach a person.
Respect their data
Say what's stored, for how long, and why.
Own mistakes
When AI gets it wrong, apologise and fix it fast.
Transparency builds trust.
Day 98 / 100 · AI features · Build vs buy for AI
Own the difference. Rent the rest.
Most teams don't need their own models. The advantage is usually in your data, your workflow and your user experience.
Buy a tool
Off-The-Shelf
“Is a generic tool good enough?”
Gain: speed
Cost: generic, little control
Build on APIs
Models + Your Product
“Can our data and UX make it better?”
Gain: fit and control
Cost: evals and upkeep
Train your own
Fine-Tune Or Train
“Is there no other way?”
Gain: specialisation
Cost: data, skills, time, money
Prove value before you build the engine.
Day 99 / 100 · AI features · Launching AI features safely
Launch AI in stages.
AI behaves differently with real users than in demos. Roll out gradually, with the safety checks in place before each step.
Internal
Your own team uses it daily.
TRUSTED BETA
A few willing customers, watched closely.
LIMITED
A share of users, with monitoring.
GENERAL
Everyone, with the safety nets still on.
Evals passing
Quality holds on real examples, including edge cases.
Abuse testing
Tried to break it: prompt injection, misuse, private data.
Monitoring and feedback
Live quality signals and an easy way to report problems.
A kill switch
Turn it off instantly, without a release.
Legal and privacy review
POPIA and customer terms checked before launch.
Support ready
The team knows what it does and what to say.
Impressive demos aren’t evidence.
Day 100 / 100 · AI features · Day 100
The craft changes. The job doesn’t.
AI makes the work faster. It doesn't change what the work is for: solving real problems, with evidence, for real people.