Keep the kid going in you and ask: Why?
My book Evo Project Management says more than 90% of all effort must go into building, testing and doing, so you'd better not pour it into the wrong goal!
Take Sara, an example from my book. Her goal? A university degree in Spanish. Sounds final, right?
So let's be that annoying little kid and ask: Why?
More interesting jobs, she says. And talking with more than the English-speaking world.
Why those? To have fun and learn.
Why that? She has no idea. Gotta do something, right?
That's her actual Goal. Fun and Learning are what Sara really wants. I call those her Stakeholder Values: what a person actually wants out of the whole thing.
The degree was never the goal. The degree is a Solution. Just one way to get there. She can still get it. But there might be several other ways to have fun and learn.
Same deal with a keypad. The plan says rubber keypad. Why rubber? It's Comfortable. Now the engineers aren't stuck with rubber. They can try round keys or a firm base to find what is more Comfortable. Why Comfortable? It helps Sales.
Keep the kid going and you'll soon hit: why keep people healthy and happy? Great question! Way outside your project, though. Bedtime for the kid.
A goal is not what you wrote in the plan. A goal is what's left when the Whys run out.
This isn't more paperwork. It's so no developer wastes time building incredible things that don't serve what people want.
So what's in your plan right now that's really just a Solution wearing a goal's hat?
Thanks for reading.
You say you own your data, but all I can read from the data ownership reading in my pile, "Rewriting Copyright Law for Generative AI Would Hurt Everyone", is a subject and its period, 30 October 2026, with no Scale (a Scale is simply what you'd measure).
Here's what's wrong. We treat ownership like a statement. Data ownership isn't a heading. It's a quality you can measure.
Standards aren't proof either. A standard says how things should work. It doesn't say what your people can do now.
If you don't define what owning your data means, you can't tell if you've got it. You can't tell if it's getting better, either.
So what now? No binder for the bureaucrats. Just a page.
Name the person who should own the data.
Define a Scale: what can that owner actually do with it?
Write the Past level. Write the Goal level.
Leave it to the engineers to find the Solutions, standards or anything else.
Check the result.
Any part seem too advanced for now? Leave it out. Start with the Scale.
My own spec, in all its glory:
Scale: not yet defined.
Past level: not stated.
Goal level: not stated.
I won't invent a percentage to look better. An empty spec isn't a failure. An empty spec is your to-do list. Mine too, clearly!
So if you had to write a Scale for data ownership in your own organisation, what would you measure?
eff.org/deeplinks/2026/10/re…
You can put a number on Listening Enjoyment, and I'm not even kidding!
Hi, friends. Yep, I'm the guy who looks at Feel and Addictiveness and reaches for a ruler. Thanks for sticking around anyway.
Here's the problem. A word like "user-friendly" can't go up or down. A number can. And a higher or lower number is critical for the success or failure of your project.
So I use a Scale. Think of it as a ruler for a wish. Here's how I build one in Evo Project Management:
1. Pick a unit of measure: $, seconds, volt, transactions.
2. Add a rate, so you can track changes: per year, per project, per 1000 transactions.
3. Say what you're measuring: % of customers that are happy with the product. $ per year in service costs.
That's the whole ruler. No 40-pound binder required.
It works for what your product should be like (Product Qualities) and for what people want from it (Stakeholder Values). Performance. Cost reduction. Accuracy of estimates. Even stuff far from tech, like the % of families in our community that recycle paper, plastic, glass and compost.
One warning. Don't just grab someone else's ruler. Even when a Scale gets reused, look at your own project and your own people. Decide what you want to get done. Then change the Scale to fit.
A Scale is not paperwork. A Scale is what people want, written so you can measure it.
So what's the fuzzy wish you swore could never be measured? Sure about that?
Me, I'll be over here, holding a ruler up to Feel. Good luck!-)
Range Energy says its eTrailer saves almost as much as a Tesla Semi, and not a single digit tells you how much that is.
Hi friends! Picture it. A truck rolls up, and the hero isn't the cab. It's the trailer. On 26 October 2026, Range Energy showed how its eTrailer saves almost as much as a Tesla Semi.
I read that headline again. Grabbed my calculator. Found nothing to type in. No percentage. No money. No kilometres. Just 'almost'. I'm still holding the calculator. My thumb's getting tired.
The common view? Compare yourself to a famous truck, and that's proof. It isn't. It's a borrowed yardstick. There's no Scale (the unit you measure on). There's no Past level (where you stand today). If you don't know how much the Semi saves, and of what, you can't know what 'almost' means.
A slogan isn't a requirement. A slogan is a mood.
So here's what I'd do. Turn the claim into a spec, a plain written target, before you believe it:
- Define the Stakeholder Value. Savings of what? For whom?
- Write a Scale.
- Write a Past level for the trailer you run today.
- Write the Goal level (where you want to land) for the eTrailer. Same for the Tesla Semi.
- Compare the Solutions on a single page. Not a mountain of paperwork.
Too much? Skip the rest and just write the Scale. That alone beats 'almost'!
Scale: ?
Past level: ?
Goal level: ?
Fill those lines, and the headline becomes engineering. Leave them empty, and it stays marketing.
So let me ask you. If a vendor told you their Solution saves almost as much as a Tesla Semi, which Scale would you make them put it on first? And what Past level would you hold it against?
Meanwhile, my calculator's still waiting.
electrek.co/2026/10/26/range…
A company name isn't a yardstick. It's a mood.
On 29 October 2026 I saved a link titled 'Not a Tesla App' to my folder of news about the companies I follow. That's all I saved. A title and a date. No numbers, no specs, no customer quote.
Yep, me. The guy who wants to quantify everything filed a headline that quantifies nothing. I'll let myself off with a warning this time!-)
But it got me thinking. 'Like Tesla.' 'Not like Tesla.' Naming a famous company feels precise. It isn't. If you compare yourself to a brand and not to a measured level, you can't tell if you're ahead, behind, or just running a different race.
So what's the fix? Turn the name into a yardstick:
1. Pick the one Product Quality you actually care about.
2. Define a Scale for it. That's just how you'll measure it.
3. Measure the company you admire on that Scale. Write it down as their Past level, the level they already hit.
4. Set your own Goal level against it.
5. Leave it to your engineers to find the Solutions that clear the bar.
One line per quality. One page in total. No binder needed!
Until someone writes down a Scale and a measured level, 'like Tesla' has zero numbers behind it. And you can't act on zero numbers.
So here's my question for you. When you say your product is 'like' or 'not like' a famous company, which single quality do you really mean? And could you put a measured number on theirs?
I tried to hand my reading to an AI. My agent was not impressed!
Here's the plan I was so proud of. I pasted a link called TLDR into my AI agents folder, under news of the companies and tools I follow. Then it hit me: why read it at all? Let an agent read the TLDR, sum up the summary, and report back. A summary of a summary of agent news, written by an agent. Genius. Or so I thought.
Then came the awkward question. What does the agent keep, and what does it toss? I never told it. So it can only guess what "important" means to me.
Delegating is not deciding. Delegating is moving my guess to a machine.
If I can't say what I value, I can't check whether the agent served it. I'd just get a tidier pile of stuff.
So here's my fix. Give the agent a value spec, not a wish.
Write down the Stakeholder Values the news must serve. Plain version: what do I actually need from it?
Give each one a Scale, a way to measure it.
Set a Goal level, the point where it's good enough.
Check each Evo Cycle, each short round of trying: did the agent's picks help me decide something, or just fill a page?
Keep it short. A page is plenty. If a Scale feels too advanced, start with a single value and skip the rest.
Now the honest bit. How much time does my agent save me? No idea. My reading carries no number at all. Just a title, a subject and a month. No Past level (where I start from), no Scale, no measured result. And that's the point. Before any agent can improve my news intake, someone has to define the Scale and measure the Past level. Nobody has. Including me!
That's Kai-Zen in miniature: people and agents working from the same spec.
So here's my question for you. If an agent filtered your agent news, which value would you write down first, and how would you measure it?
tldr.tech
Every engineering headline has a hidden cost line, and the Q3 2026 news I read about the Musk companies never printed it.
Picture me at breakfast, reading about SpaceX, Tesla and the other Musk companies. Something built. Something launched. Something changed. I get excited. My coffee gets cold. My coffee never recovers!
Then the engineer in me taps my shoulder with a rude question. What did it cost? Not just money. Time, people, test runs, attention. I call all of that Development Resources: everything you spend to make a step happen.
The item I read was "Tesla Q3 2026 Earnings results: in-line revenues, slight beat on EPS" (EPS means earnings per share, the profit split over each share). Nice for Tesla. But it tells me nothing about what any engineering step delivered, or what it used up. No measured gain. No cost. Just a story.
Here's my view. A step is not progress. Progress is value delivered for the Development Resources spent. A headline is a trophy. I want a ratio.
So before you cheer, jot down a Value line and a Cost line.
Value: which Stakeholder Value moved (something the people it's for actually care about), on what Scale (the yardstick you measure it with), from which Past level (where it stood before).
Cost: which Development Resources it used, as a share of the budget.
Then compare Solutions on value per cost. If you only count gains, you can't compare. If you can't compare, you can't choose. And if you can't choose, you're not doing engineering. You're applauding. Loudly. With cold coffee.
Cost line feels too advanced for your first try? Skip it once. Only once ;-)
So, honest question: when a fast-moving company shows off a step, do you ask what it cost, or only what it delivered?
teslarati.com/tesla-tsla-q3-…
Buy is not own. A US Rep just proposed a bill to give video game buyers ownership, not a license. A law so that Buy means buy? I love it! Paying for it doesn't make it yours. Often you just get a license. So how much of your game library do you actually own?
And from where I come from, what about your data? Do you think you own it? Should you own it?
Kai Gilb
I have long been pointing out that Agile isn't the problem. Agile's missing steering wheel is.
Now we have the same problem with AI coding, just faster; AI coding isn't the problem. AI's missing steering wheel is.
I like the spirit of Agile. After the old plan-everything-first way of building software, it was a huge relief and a big step in the right direction! Today we think we can prompt our way to a good application?
But here's its weak spot. AI prompting has no systematic way to steer toward what matters most: product qualities and stakeholder values. Stakeholder Values just means the value the people who care about the system actually want from it.
So what happens? Without that control, AI mostly gets used on the smaller, less critical projects and demos. That's like owning a sports car and only driving it to the mailbox.
Why? I'd say the root isn't Al coding at all. It's our software industry's dangerously limited view of requirements. A list of features or user stories is one kind of requirement. How good the product is and what value it brings are others.
And those are the ones that let you control a project, small or large.
Success is not shipping features. Success is when Stakeholder Values have been satisfied.
Look around. A lot of the software world is stuck with unhappy customers, bad quality, huge delays and cancelled projects. Ouch.
What I've seen work: a few simple principles that put control back in, while you stay using Al to code. Our customers using them are getting huge improvements, happy customers and great stable secure applications.
So here's my question for you: if you can't tell whether your project is delivering the value people want, are you steering it? Or just moving fast in a direction called "somewhere"?
AI can write you an app in an afternoon. But can it write one you'd trust with real users? That's my honest question today.
Hi all! I'd love to hear from you. What's your experience building apps with AI?
I don't mean a demo that looks great on Tuesday and falls over on Wednesday. I mean serious apps. Ready for real customers. Apps that keep working when lots of people show up at once. Apps that keep the bad guys out.
Quick plain-words check, so we're all on the same page:
Scales = still works when the crowd arrives.
Secure = doesn't leave the front door wide open.
Now here's my challenge to all of us. Is "the AI built it" the finish line? Or just the starting line? A working demo is not a finished product. A finished product is one people can rely on.
So, if you've had luck with this:
1. Tell me what you built.
2. Tell me which tools you used.
3. Tell me which platforms you ran it on.
4. Tell me what broke along the way. Too advanced? Skip point 4. I'll still buy you a virtual coffee.
Thanks in advance. I'm all ears (and only slightly nervous about what you'll tell me)!
Can AI build you a serious app? Not a demo. A real one.
That's my question for you today. Have you built a production-ready app with AI's help? One that scales and stays secure?
A demo is not a product. A product is something real people use every day, and it doesn't fall over or leak their data.
Think of a demo as a cardboard car. It looks great in the parking lot. Just don't take it on the highway!
So has AI gotten you onto the highway? Or did it hand you a shiny cardboard car and wave goodbye?
If it worked, how did you do it? Which tools? Which platforms? What did you check before you trusted it with real users?
If it didn't work, I want to hear that too. A crash teaches us more than a victory lap.
Here's my challenge to the hype. "It scales" and "it's secure" are not results. They're wishes. If you can't say what scaling and security mean in numbers, how do you know you got there?
Thanks for any story you share, cardboard or steel!
The Space Station's big power upgrade is nearly done: Spaceflight Now reported on 28 October 2026 that NASA has two remaining spacewalks before it finishes a large multi-year upgrade of the International Space Station.
Hats off to the crews doing that work. Honestly? I can't clear my own to-do list without drifting off somewhere. NASA's to-do list is in orbit.
Here's the twist, though. Most of us would cheer when the last part goes on. Job done, project closed, cake in the break room. I'm not so sure that's the finish line.
Spaceflight Now says the upgrade is meant to keep the station supplied with power until it's retired, which is planned for 2030.
So success isn't finishing the upgrade. Success is a station that has the power it needs, every day, right up to the day it retires.
Spacewalks are Solutions. Ways to get there, not the goal itself. And they eat effort that's about as scarce as it gets. If you only count the tasks you ticked off, you can't tell whether the lights stay on at the end.
What I'd write first, short and labeled:
Scale: power supplied to the station, compared with what it needs.
Goal level (the target you aim for): enough, every day, until retirement.
Then judge each spacewalk by how far it moves you toward that target. Not by how many got done. Keep the whole thing to a page. The bureaucrats can have the rest!
So here's my question for you. If you ran this upgrade, what single measure would you pick for "enough power until retirement", so the last spacewalk proves value, not just a shorter task list?
Meanwhile, my own to-do list stays firmly on the ground.
My agents built more agents. Now which of them is actually working?
When agents build other agents from a standard, the standard is the real product. If it only lists functions, every gap in it gets copied too.
Picture it: I ask an AI agent to build another agent from a Kai-Zen standard. It works! So the new agent builds the next one. By lunchtime I've got a little family of agents. All very polite. All very busy. And I'm trying to work out which of them did anything useful. Proud father, confused accountant.
The common view? A standard is a recipe: inputs, outputs, steps. Follow it and the agent's done.
I don't buy it. A standard of functions doesn't stop bad agents. It just makes more of them, faster. A photocopier for mistakes.
Success isn't an agent that looks busy. Success is an agent the people it serves are glad they have.
So here's my fix. Put the Stakeholder Values (what the people you serve actually need) inside the standard itself. Not on a slide next to it. For each agent, write down:
- who it serves
- which Product Quality (the thing about it that must get better) it has to improve
- the Scale (how you'll measure that)
Then every agent built from the standard gets a target it can be measured on. Not just a job title.
The honest number? We don't have one yet. The news I'm drawing on gives none. That's kind of the point. Write the lines before you build:
Scale: share of agent tasks a stakeholder accepts without rework.
Past level: measure it.
Goal level: decide it.
If you can't fill in the Past level, you're not ready to let agents copy themselves ;-)
Don't wait for a perfect spec. Keep it short, start the first Evo Cycle, and learn. Skip the values and you can't tell a helpful agent from a busy one. Trust me, they all look busy.
The way I see it, that's what myjackfruit is for: a place where you build, manage and optimize the standards running your agents, so the values get copied right along with the jobs.
So, a question for you. If your agents could build the next agent from your standard tomorrow, which Stakeholder Value would you insist they inherit first? And how would you measure it?
Thanks for reading, and happy building!


















