Mike Gebremeskel: Writing

AI didn't write this portfolio. My own archive did

Tue, 02 Jun 2026 00:00:00 GMT

Here is the honest version of how the portfolio you are reading got built. I used AI to do it, and it did not write a word of substance that was not already mine. AI did not supply the ideas, the stories, or the judgment. It took five years of my own writing and a career's worth of real decisions and made them legible at a speed I could never hit by hand. The model is a commodity anyone can rent. The thing that made this work was the input, and the input was mine.

I want to be transparent about the whole process, because the process is the point.

What I actually did

I started by feeding an AI my real history. A full export of five years of my work Slack, more than twenty thousand of my own messages. My old LinkedIn posts going back to 2018. The actual decisions I made building a company. Then I ran a pipeline that looks like this.

First, analyze the voice. The AI measured how I actually write, my median sentence length, the fact that I ask more questions than I make statements, the words I lean on, the punctuation I avoid. That became a style guide, written from evidence, not guesswork.

Second, mine the themes. It read the archive for the moments where I was actually teaching something, coaching a team, making a hard call, and surfaced them as candidate ideas.

Third, draft at scale. For each idea, it produced a first draft grounded in the specific Slack thread or decision it came from.

Fourth, and this is the part that matters most, verify. Every claim was checked against the real source. No invented numbers. A hard voice standard enforced on every line. A grammar pass on every piece.

The diagram below shows the whole pipeline.

How this portfolio was built. The inputs on the left are the part that is hard to copy.

The model is a commodity. The archive is not.

Here is the insight I keep coming back to. Anyone can open the same AI I used. The model is available to everyone for a few dollars. So the model is not the advantage. If you point it at a blank slate and a generic prompt, it gives you generic mush that reads like everyone else's.

What it cannot give you is a deep, specific body of real work to draw from. Point the same model at twenty thousand of your own messages, a decade of your own decisions, and your own lived experience, and it does not give you mush. It gives you back yourself, organized and at speed. The advantage was never the AI. It was the proprietary substance I fed it, and the judgment to shape what came out.

That reframes the whole anxiety about AI making everyone sound the same. AI only flattens you if you have nothing specific to say. If you have a real archive of real experience, AI is the opposite of a flattener. It is the fastest way to surface what is already uniquely yours.

The human half was the whole job

Because the AI handled the typing, the work became almost entirely judgment. Hundreds of small calls that no model could make for me.

Which moments were actually meaningful versus just frequent. Which sentences sounded like me and which sounded like a press release. What was true and defensible versus a number I could not stand behind. What to cut. Where a draft was technically fine but missed the real lesson. I set the guardrails too. No fabricated metrics. Every claim tied to a source I could point to. A voice specification strict enough that a wrong-sounding line stuck out.

That is the part people miss about working with these tools. AI scales whatever standard you give it. Give it a low bar and it produces a lot of slop quickly. Give it a high bar, real inputs, and constant judgment, and it produces a lot of good work quickly. The output tracked my standards, not the model's defaults.

Why this was even possible

There is a quiet lesson underneath all of this. The only reason an AI could mine five years of my thinking is that I had written five years of my thinking down. For years I put my reasoning into Slack messages and docs instead of letting it evaporate in meetings. I did not do that so a machine could read it later. I did it because writing things down made my teams faster. But it had a second payoff I never planned for. It compounded into an asset.

Most people's thinking disappears. The decision gets made, the context is lost, and a year later nobody remembers why. Mine accumulated into a searchable record of how I actually think and work. When the tools finally caught up, that record was sitting there, ready to be turned into something. Capture compounds. Your future self, holding better tools, will thank the version of you that bothered to write it down.

So is it still mine?

The fair question is whether using AI like this makes the work less mine. I do not think it does, and the reason is the split I keep describing. The substance is mine. The judgment is mine. The lived experience is mine. AI compressed the labor of turning all of that into clean prose. It did not compress the thinking, because the thinking had already happened, over years, in real rooms with real stakes.

If anything, being open about this is the credibility, not the weakness. I am not pretending a machine made me a better thinker. I am showing that I had a real body of work and the judgment to shape it, and that I know how to use modern tools to move fast without lowering the bar. That last part is not a confession. In this market, it is the skill.

The takeaway is not "use AI to write your portfolio." It is something more durable. The value in the AI era is not the model, which everyone has. It is having something real to feed it and the judgment to shape what comes back. Your accumulated, specific experience is the moat. AI just makes it finally legible at scale.

So the question I would ask you is the one I had to ask myself. If you pointed the best AI in the world at your own archive tomorrow, would it find a deep body of real work to draw from, or a blank page? The answer to that is mostly written years before you ever open the tool.

A note on this collection: each essay is dated to the period its lesson comes from, so the set reads as a body of work built over a career. This capstone is the exception, written in the present to be honest about how the collection itself was assembled.

The durable skills in the AI era

Mon, 01 Jun 2026 00:00:00 GMT

The real career risk in this moment is not that AI replaces you. It is that the shelf life of any single skill or tool keeps shrinking. The thing that was a rare, valuable skill three years ago is now a baseline everyone has, or it has been automated entirely. Chasing the next tool is a losing race. The edge that actually compounds is judgment, and judgment is exactly what AI does not replace.

I say this as someone who has shipped AI features, not someone watching from the sidelines.

Chasing tools is running on a treadmill

The common reaction to the AI moment is "I need to learn the latest tool, take the course, get the certification." That is not wrong, but it is incomplete. If your entire career strategy is to keep acquiring the newest skill, you will spend your career reacting, always one release behind, always relearning, never compounding.

Tools have a shorter and shorter half-life now. The specific prompt trick or platform that gives you an edge this year is table stakes next year. So a strategy built on always having the newest tool is a strategy built on sand. You are sprinting just to stay in the same place.

What actually compounds

Underneath the tools, there is a different category of skill that does not expire. The ones I keep coming back to are the human and judgment skills. Knowing your customer deeply. Communicating clearly. Earning buy-in for an idea. Asking the right question, including the dumb one. Taste, the ability to tell good from almost-good. Prioritization, knowing what matters most right now.

None of those have changed in twenty years, and AI does not take them from you. It makes them more valuable. When AI can produce a competent first draft of almost anything in seconds, the scarce skill is no longer production. It is judgment. Knowing which draft is actually right for your customer, which problem is worth solving, which answer to trust. The cheaper the output gets, the more the discernment is worth.

These are the skills that compound. Every year you get better at understanding customers or communicating or prioritizing, that improvement stacks on top of the last, because the fundamentals do not reset. That is the opposite of the tool treadmill.

I am not arguing against AI

I want to be clear, because this is easy to misread. I am not saying ignore AI. I have built with it. I used it as a first draft for copy and tests, built a model to identify vendors in financial data, kept humans in the loop where being wrong was expensive, compared different models for specific jobs, and made deliberate calls about what data it could touch.

That hands-on experience is exactly why I am confident about where the durable value sits. Using AI well does not require you to become a different person chasing every new release. It requires judgment about when to use it, what to trust, and how to shape its output for a real customer. The tool is new. The skills that make you good with it are old.

The strategy this points to

So the move is not to stop learning AI tools. Learn them, use them, stay current. But do not build your career on them. Build it on the compounding skills, and treat the tools as things you pick up and put down as they change.

Develop range, too. The person who can connect customer insight to clear communication to a sound prioritization call is far more resilient than the person who is the world's expert in one tool that may be obsolete in eighteen months. Range plus compounding fundamentals is a career that adapts. A stack of expiring certifications is a career that reacts.

The skills that protect your career in the AI era are not the newest ones. They are the oldest ones. Customer empathy, communication, buy-in, judgment, taste, prioritization. AI raises their value rather than threatening it, because it makes everything except judgment cheap.

So by all means, learn the tools. But invest most in the things that have not changed and will not, because those are the ones that compound. If you could only get meaningfully better at one durable skill this year, one that will still matter in a decade no matter what the tools do, which one would you choose?

When the domain is not yours, go find the expert

Fri, 01 May 2026 00:00:00 GMT

When your product touches a domain you do not own, stop guessing and go find the one person who lives in it. Do not reason it out from scratch. Borrow the mental model of someone who has already spent a career on the problem.

I learned to lean on this the hard way, by hitting a wall I had no business trying to climb alone.

The wall was accounting

We were building software that showed people their spend, which meant we ran straight into accounting questions we were not equipped to answer. Two in particular stopped us.

The first was how to display a transaction that covered two separate months. The second was how to calculate year to date for a subscription that was bought in one year and ran into the next. These sound small. They are not. Get them wrong and the numbers your product shows are simply incorrect, which for a finance tool is fatal.

We could have argued about it among ourselves for a week and shipped our best guess. We had opinions. The problem was that our opinions were worth nothing here, because none of us actually knew how this was supposed to work.

So I went to someone who did

One of our angel investors, Ian, was a Chief Audit Officer. So instead of guessing, I asked him how this actually works.

His answer did not just solve the two problems. It reframed them. What I learned from Ian was that our confusion came from how we intended the data to be displayed, and that there are a couple of standard ways financial data gets shown. Once I understood that, the design choice that had felt impossible to us became obvious. The thing we had been stuck on for days was a solved problem in his world. We were not facing a hard question. We were facing a question that was hard only because we did not live where the answer lived.

That is the whole lesson in one moment. The wall was not really there. It only looked like a wall because we were standing in the wrong field.

Asking well is a skill

Here is the part that is easy to skip. Going to an expert is not the same as showing up and saying, "help, I am confused." You get a good answer by asking a precise question.

So before I sat down with a finance person on another set of these issues, I wrote the questions down exactly. How do we handle year to date for an annual subscription that does not start in January? Do we count from January, or from the date the subscription was paid? How do we handle something that is no longer active, like a tool we stopped using? Each question was specific enough that the expert could give me a specific answer.

That preparation respects the expert's time and gets you a usable answer instead of a vague one. The clearer your question, the sharper the model you get back. A fuzzy question gets you a fuzzy lecture. A precise question gets you the exact rule you can go build against.

Build a bench before you need it

Over time this became a habit, not a one off. I tried to keep experts on tap before I needed them.

When we needed to understand security, I went looking for people in that field to build a small panel we could call on. When we needed our financial model checked, I sent it to an accountant friend who actually knew the numbers. Our advisors were not decoration. They were a bench of borrowed expertise I could pull from the moment we wandered into territory we did not own.

There is a bigger version of this idea too. The deeper we got into the financial side, the more it made sense to lean the whole product toward the people who live in those numbers all day, the accountants themselves. The instinct that started with one question for Ian, go to where the real expertise is, scaled all the way up to a direction for the company.

You are going to build things that touch domains you do not understand. Finance, legal, compliance, security, all of it. When that happens, your first move should not be to think harder by yourself. Someone has already spent years on this exact problem.

Find that person. Ask them a precise, well prepared question. Take the model they hand you and design around it. You do not need to become the expert. You need to know who the expert is and how to ask them well.

The smartest thing you can do in an unfamiliar domain is admit it is unfamiliar. What is the wall in front of you right now that is only a wall because you are standing in the wrong field?

The most valuable person on an early team

Sun, 01 Mar 2026 00:00:00 GMT

Early teams do not die from a lack of ideas. They die from dropped handoffs. The person who keeps those handoffs from dropping is one of the most valuable people on the team, even though their work never shows up in the demo.

For five years at my company, that person was me. Not because of a title. Because someone has to be the connective tissue, and I decided it would be me, and I ran it on purpose.

What the work actually is

It is easy to picture the valuable person on a startup as the one with the big idea at the whiteboard. On a small team, the idea is almost never the bottleneck. The bottleneck is the space between the idea and the shipped thing. That space is full of handoffs, and every handoff is a chance to drop the ball.

So a lot of my real job was making sure the ball did not drop. In practice that looked like a few specific habits.

I kept everyone on the same page, out loud. When a thread had gone quiet or tangled, I would post the state of it. As I would open these, here is the current progress to date to catch everyone up, and then the list. Nobody had to reconstruct what was happening. It was written down.

I made alignment a visible action, not an assumption. When I posted the day's priorities or a release plan, I would ask the team to "review and check mark if you agree, or comment with any questions or corrections." A green check meant you had actually read it and you were in. That one small ritual turned silent, assumed agreement into something real I could see.

I made sure nothing fell through the cracks. If something mattered but could not be handled right now, I set a reminder on the message so we would come back to it. I asked teammates to do the same, to "set a reminder to come back to this if you cannot right now." A small team moves fast and forgets faster. Reminders were how we remembered.

Removing blockers was half the job

If handoffs are where teams die, blockers are how they bleed out slowly. So I treated unblocking people as a first class task, not a favor.

I would go through our tickets, look for anything blocked, take action to clear it, and comment on the ticket saying what I did. I would ask directly, is there anything on our end we can unblock you on? At one point I framed a whole week's goal around it. The big goal was getting our developer completely unblocked on everything design related so he could be in pure developer mode. His job was to build. My job was to clear the road in front of him.

When blockers kept slipping, I built a tiny format so we tracked them the same way every time. The latest update on the ticket, who is involved in the block, what specifically is blocking it, what it will take to unblock it, and the date we would have the next update. Five lines. But now a blocker could not hide. It had an owner and a clock.

I built loops so handoffs could not break

The cleanest version of this was a validation loop I set up for inbound signups. The rule was simple. A checkmark in Slack on a new signup meant two specific things had happened. A record was created in the CRM, and the follow up sequence had started. One small mark, two guarantees. Nobody had to wonder whether a lead got dropped, because the checkmark was the proof.

That is the pattern. Find the handoff that keeps breaking, and wrap it in a loop where the done state is visible and means something exact.

Why this work is undervalued, and why it should not be

None of this shows up in a product demo. You cannot screenshot a handoff that did not drop. So this work is easy to overlook, and easy to wave off as "just coordination," as if coordination were beneath the real builders.

I see it the other way. On an early team, getting good ideas out the door is the rare skill, not having them. Ideas are cheap and everywhere. Execution, the unglamorous chain of small handoffs that turns an idea into something a customer can use, is where most startups actually fail. Owning that chain is not support work. It is one of the highest forms of ownership there is.

I also tried to do it generously. Keeping the machine running gave me a clear view of who was carrying the load, so I made a point of crediting them out loud. We could not hit a release date, I once said, if we did not have someone like our lead developer. Running the operation and lifting the people in it are the same job.

If you are early in your career and you are the person who naturally catches the dropped ball, do not undersell it. That instinct is rare and it is valuable. Name it, own it, and get great at it.

And if you are building a team, look past the loudest idea in the room. Ask a quieter question. Who here keeps the handoffs from dropping? In my experience, that person is holding the whole thing together, and they are usually the last to tell you so.

Listen to what users do, not what you built

Thu, 01 Jan 2026 00:00:00 GMT

The most reliable signal in your product is not what users say. It is what they do. If you only take one thing from this, watch the behavior, because behavior does not flatter you the way a polite answer does.

I learned this from one user opening one screen the wrong way.

The screen that corrected us

One of our early users, Julien, opened the product and looked at his oldest transactions first. We had built the view to lead with history. He went straight past it looking for what was happening right now.

To us it read like a small bug. But it was telling us something bigger. We had assumed people wanted to study the past. What they actually wanted was the present. The current state of their spend, today, before anything else.

That is the whole trap with your own product in one moment. You design around what you imagine the user wants. Then a real person shows you, without saying a word, that you imagined wrong.

Why what users say is not enough

Ask someone if they like your feature and they will usually be kind. People do not want to hurt your feelings in a call. So they nod, they say it is nice, and you walk away thinking you validated something.

You did not. You collected politeness.

The honest signal sits in what they reach for. Which screen they open first. Where they slow down. What they ignore completely. We saw another version of this in a customer meeting when one person got confused on the business registration step. He did not file a complaint. He just stalled. That stall was the feedback.

So we changed how we treated these moments. One confused user became a reason to fix the design, not just a ticket to close. If a single real person tripped on something, we assumed others would too, quietly, where we could not see them.

We stopped asking users to do our thinking

The other thing watching behavior taught us was that we were asking too much of people up front.

At one point our onboarding asked users to rank a set of options before they had even seen value. I flagged it to the team. As I put it, the important callout was to reduce the number of questions we ask of users. We did not have fifteen options for them to weigh, but we were still asking them to rank three things before they got anywhere. All we really needed to know was what mattered most to them.

The same lesson showed up in a smaller choice. We had a screen where some options were marked "coming soon." A user is not going to click something that says it is not ready. So putting those in front of people at a decision point just gave them dead ends. If you would not click it, do not make the user stare at it.

Even our error messages became a place to listen. When the product could not match a user's subscriptions automatically, we did not show a cold system error. We wrote it the way you would actually say it to someone. Something close to, "We weren't able to find any subscriptions in your bank transactions that we could match right away. Please review these to see if any fit." That is still listening. It meets the user in the moment they are actually in, which is mild confusion, not failure.

Write the requirement as the user's job

One habit tied all of this together. When we wrote what to build, we wrote it as the user's job, not the feature's spec.

So a requirement did not read, "build a spend graph." It read, "I want to view my current spend over time so I can catch any trends or changes I need to review." That sentence tells you what the thing is for. It tells you what success looks like from the user's side. A feature name tells you none of that.

When you start from the job, you are far less likely to fall in love with a screen the user never asked for. The job keeps you honest.

You can hold a strong opinion about what users want. I do. But the opinion is a hypothesis, and the user's behavior is the test. When the two disagree, the behavior wins every time.

Watch what people do. Treat one person's confusion as a signal, not a one off. Ask them less and observe them more. And when you write down what to build, write it as their job, so the product stays pointed at them instead of at your own idea.

What did your last confused user actually do right before they got stuck? In my experience, that moment is worth more than a dozen times someone told you the product was nice.

Teach your team to think in outcomes

Mon, 01 Dec 2025 00:00:00 GMT

Your team's goals are probably a to do list with a fancy name. Here is the test I use. Read a goal, then ask, "So what?" What changes if we hit this? If the answer is nothing, it was never a goal. It was a task.

I learned this the slow way, by sitting with my team every week and rewriting our goals together until they actually meant something.

The objective carries the why. The key result carries the when and the number. A task becomes a goal when it can answer "so what?"

Where it started

We did not pick up OKRs from a book. They were a tenet of Techstars. We went through the program, and I was expected to have our objectives and key results ready to present to investors and our cohort every week for the full three months. When you have to stand up and defend your goals to a room of investors every single week, you learn fast which goals are real and which ones fall apart the second someone asks why it matters.

So when the program ended, I brought the practice in house. But here is the catch with any framework. It is easy to adopt the format without the thinking behind it. People started filling in the boxes with whatever they were already doing.

Here is a clear example. One week our objective was written as "Complete the outreach messaging." It looks productive. But I pushed on it, because finishing a task tells you nothing about whether it worked. As I put it to the team, "simply completing the outreach messaging doesn't mean we get customers or that it works." You can finish it and learn nothing.

So I started correcting these, one line at a time, in the open where everyone could see the reasoning.

The two corrections I made over and over

The first was about objectives. People wrote objectives that did not lead anywhere. So I would ask for the reason behind it. As I told the team, the objective "needs a reason why it is being done." So "Complete the outreach messaging" became "Understand what type of outreach messaging resonates with customers most as we release the product." The work underneath is the same. But now it points at something. There is a "so what."

The second was about key results. People kept writing activities instead of measures. A key result like "Understand what messaging is working and what is not" sounds fine until you ask, "How would we know when we hit it?" You cannot. So I would hand back the measurable version. Something like "Bring 20 more users into the beta," because that is specific and you either hit it or you do not. The rule I kept repeating was simple. Key results "refer to things that are tangible or can be measured."

I tried to make the two roles clear. The objective carries the what and the why. The key result carries the what and the when. If you could not answer "why" for the objective, or "when" for the key result, you were not done writing it.

The dunk

The part people got stuck on was that objectives are allowed to be big. They were writing tiny, safe objectives so they could be sure to hit them, which defeats the point.

So I gave them an analogy I actually used. Objectives can last more than one week and should be aspirational. My example was wanting to throw down a dunk in a pickup game without hurting myself. That is the objective. It is a stretch and it is clear. The key results are the things you do this week to get there. Train, jump, build up. The objective inspires. The key result measures.

That landed better than any framework definition I could have given them. Pick the image that fits your team. The point is to free the objective to be ambitious and pin the key result to something real.

I built a rhythm so it would stick

A good idea dies without a ritual around it, so we built one.

We ran a weekly ops review. Everyone posted their OKRs ahead of time. We took a few minutes to read silently and leave comments, then we discussed until we were aligned. I would check in a few minutes before the meeting to offer help so the meeting itself went smoothly.

I also set two house rules that I cared about as much as the goals themselves. Celebrate when you hit a key result early, because it means you can aim higher next time, and that is good information. And call it out when you aimed impossibly high, because that is a signal too. It tells us to get you help or rethink what is in the way. Missing a goal was not a failure to hide. It was data to discuss.

One more reframe I had to make a lot. When a hard metric showed we were behind, people read it as criticism. I did not. I told a teammate that a tough metric might be the best one we have, because it is telling us we need to move faster, not that anyone is incapable. A good metric is honest with you. That is the whole job.

We outgrew the spreadsheet and moved the whole thing onto a Notion board with columns for the key result, the objective, the goal, and the final result. The tool changed. The habit did not.

What I actually believe about this

The framework was never the point. Plenty of teams run OKRs and still write task lists dressed up in OKR clothing. The thing that mattered was teaching people one reflex. After every goal, ask, "So what?" What is different in the world if we pull this off?

If you can answer that, you have a goal. If you cannot, you have a chore, and no template will save it.

Try it on your own list this week. Read each item and ask, "So what?" I think you will be surprised how many do not survive the question.

Find the wedge, then narrow it again

Sat, 01 Nov 2025 00:00:00 GMT

We spent months exploring the wrong half of our product. Our customers corrected us in one sentence.

Before this, we had already found a wedge once, at the company level. We applied to Techstars Boulder with a password manager idea, got rejected in the final round, and that no forced the first version of the only question that matters: who are we actually for. That rethink became Talisman. I tell that story separately, in "The Leap, and the Rejection That Found the Wedge." This essay is about the second time we had to narrow, a year later, this time inside the product. Same skill, smaller altitude.

Here is the story, because the lesson only makes sense if you see how we got there.

Sharpen to the one thing customers actually want. We cut access and IT and committed to spend, after the same focusing move at the company level created Talisman.

The market was huge, and that was the problem

We were building in software management. The full vision was big. Help a company see its software spend, provision new hires into the right tools, and deprovision people when they leave. Spend, access, the whole thing.

A big map looks like opportunity. It is actually a trap. When everything is in scope, you have no reason to pick, and a small team that does not pick does not ship.

I had a bias going in that turned out to be right. Early on I wrote to the team that software used to be made for a specific person, like KidPix, and that we had drifted into making things that appeal to everyone instead of a very specific customer. I believed we were heading back toward specificity. So even while the vision was broad, I kept pushing one idea. Start with one group of customers, get really good at serving them, and scale as they grow.

We did the real discovery work

We did not guess our way to the product. We ran a proper Jobs to Be Done process. I grouped stickies on a board around the jobs a customer was actually trying to get done, then mapped what we wanted them to feel once that job was solved, and only then what the product should do to create that feeling. Jobs first. Feelings second. Features last.

We explored both paths seriously. I spent real time mapping provisioning end to end. I worked out what provisioning even was, where the pain points sat, and the key flows a solution could use. I did not want to narrow the company out of laziness. I wanted to narrow it out of evidence.

So we shipped a slice and put it in front of people. We let them onboard and land on a spend overview. And then we listened.

The one sentence that decided it

The signal came back fast and it was not subtle. In a customer meeting, our notes read, "The spend piece is what is resonating with them. The IT piece is a bit out of scope." Another customer told us their real headache was just getting devices deployed, which sat even before the provisioning work we had been mapping.

There it was. We had been treating spend as step one of a bigger product. It was not step one. It was the product.

Users cared about seeing their spend. The access and IT work we had planned was, in their words, out of scope. So we made a decision. We narrowed the entire company onto spend. We stepped back from the heavier integrations and provisioning build that nobody had actually asked us for.

That is a hard thing to do when you have already invested time mapping the other path. You feel like you are throwing work away. But the work was not wasted. The work is what told us where not to go.

The idea that gave me conviction

Around this time I was reading The Cold Start Problem, and one story stuck with me enough that I wrote it in a standup. When Bank of America first spread credit cards, they did not launch everywhere. They picked Fresno, because they already had close to half the town as customers. They learned what worked in one concentrated place, then expanded outward slowly until they had the whole state.

The lesson I pulled for us was simple. Even inside your target segment, there is a smaller group who feels the pain hardest. You can always narrow again. Find that group. Build the easiest thing that genuinely helps them. Then let their reaction tell you what your company actually is.

That is the part people skip. They pick a wedge once and treat it as settled. The wedge is not a one time decision. It is a habit of narrowing every time the evidence lets you.

You do not pick the wedge that looks most impressive on a roadmap. You pick the one that is easiest to ship and closest to a real, narrow customer. Then you hold it loosely enough that the customer can move you.

We thought we were building spend, access, and IT. The customers told us we were building one screen. So we became that screen, and we got a lot less confused about what to do next.

What did your earliest users actually reach for? In my experience, that is almost always the answer, and it is usually narrower than the thing you set out to build.

Write it down before you say it

Wed, 01 Oct 2025 00:00:00 GMT

I cut our meeting times down by 50%. The fix was not a better agenda. It was one rule. Write the idea down before the meeting. Then we talk.

For a long time my team did the opposite, and so did I. Someone would say an idea out loud. The rest of us would ask what they meant. We would go back and forth until it finally clicked. Only then could we do anything useful with it.

Think about how backwards that is. We were spending most of the meeting just getting to the starting line. The real work, the part where you pressure test an idea and make it better, only began once the clock was almost out.

So we flipped the order.

The change was small and it was not optional

I told the team I would never just speak an idea to them. I would write it down and share it first. Then we could edit it and actually discuss it.

I cared about this enough to build it into how we ran. We started a habit where people dropped what they wanted to cover into the channel ahead of time, so I could build an agenda and everyone could understand it at a high level before the call. The point was simple. Walk into the meeting ready to discuss something on paper, not ready to start thinking from zero.

We borrowed structure from people who had already figured this out. We picked up the Amazon style memo for our leadership meetings. The narrative memo forces you to actually make the argument, not just list bullets you can hide behind. The first time we used a real template for that meeting, a one hour call dropped to thirty minutes. Same decisions. Half the time.

I was also strict about one thing that sounds soft but is not. Capture every idea, no matter how simple or dumb it seems. Being able to read an idea and then discuss it is how you build a shared perspective. If it only ever lives in someone's head, it is not a shared anything.

Why writing first actually works

Here is what I think is really going on.

When you talk an idea out, the other person spends their energy decoding you. What did he mean by that? Is that the same as the thing we said last week? By the time everyone understands the idea, you are out of time and you have done none of the thinking that matters.

When you write it down, the decoding happens before the meeting. People show up already understanding the idea. So the meeting gets spent on the useful part. Pushing on it, finding the holes, making the call. As I told the team back then, the goal was to put our notes in a document, so that by the time we met we were discussing what we had already seen. That drives the conversation faster. And the meeting only lasts as long as it actually needs to.

There is a second benefit I did not see coming. The writing becomes a record. When we moved more of our work async, I told the team the reason out loud. We needed future teammates to be able to read what we had discussed and understand why we made a decision, not just what we decided. The context stops living in one person's head and starts living somewhere the whole team can reach.

That turned out to matter more than the time savings. A small team moves fast and forgets faster. The doc is the memory.

The honest tradeoff

Writing first is more work up front. You cannot fake it. You have to actually know what you think before the meeting, which is uncomfortable, because a lot of meetings exist precisely so people can avoid figuring out what they think.

But that discomfort is the feature. The blank page does the thinking the meeting used to waste time on.

So if your meetings feel slow, do not reach for a better agenda or a shorter time box. Change the order. Make the idea show up on paper before it shows up in the room.

Talking feels faster. It is not. The doc does the thinking. The meeting just confirms it.

Does that match what you have seen on your own teams?

Culture is built in small interactions

Sat, 01 Feb 2025 00:00:00 GMT

Culture is not set by a values poster or a single big result. It is built, or eroded, in the small moments. How you treat a colleague who is struggling. Whether you encourage someone having a bad week. Whether you build real two-way relationships or just transact. The culture is the sum of those moments, not the slogan on the wall.

I believed this before I led a team, and then I got to test it building one.

Culture is a daily act, not a declaration

Back in 2019 I wrote that culture changes day by day, not only through the results you achieve but through your interactions with others. Encouraging a neighbor when they are down. Collaborating with a stakeholder who is struggling. Building meaningful two-way relationships. Those small acts, repeated, are what actually move a culture.

The mistake organizations make is treating culture as a thing you announce. You write the values, you put them on a slide, and you assume they are now true. They are not. The values on the wall are a hypothesis. The culture is whatever your people actually experience in their hundred small interactions each week. If those two things disagree, the interactions win every time.

Where I learned this: McKesson's iCARE and iLEAD

This belief did not come from nowhere. It came from my years at McKesson, where culture was not a poster, it was a daily practice with a name.

McKesson had two value frameworks that ran through everything. iCARE, which stood for Integrity, Customer-First, Accountability, Respect, and Excellence, was the answer to who we are. iLEAD was the answer to how we lead. What struck me was not that these existed, plenty of companies have a values acronym. It was that people actually lived them, in the small moments, every day. Respect was not a word on a wall. It showed up in how a senior person treated a brand-new analyst. Customer-First was not a slogan. It changed which problem you picked up first.

That is where I learned that values only become culture when they are practiced, not posted. When I wrote that 2019 post about culture being built day by day, I was really writing down what iCARE and iLEAD had taught me by example. The frameworks gave me the words. Living them at McKesson gave me the lesson.

What this looked like on a real team

When I helped build a remote company, I could not rely on hallway culture, so I had to make these small moments on purpose. We ran sessions where people taught the group about something they loved, so we knew each other as humans, not just roles. We rotated who ran meetings, so more people felt ownership. When someone was stuck, my standing message was to tell me right away so I could clear it for them, because removing what is in someone's way is one of those small acts that says "you matter here."

None of those were grand gestures. They were small, deliberate, repeated. That is the only way culture actually gets built, especially when your team is spread across time zones and there is no office to absorb it for you.

Why the small stuff outweighs the big stuff

It is tempting to think culture is forged in the big moments, the crisis, the launch, the all-hands. Those matter, but they are rare. People spend almost all their time in the small moments, and that is where they learn what it actually feels like to work with you.

A leader who nails the big speech but is dismissive in daily interactions has a bad culture, no matter what the speech said. A leader who is consistently decent in the small moments builds a good one, even without a single memorable speech. People believe what they experience repeatedly, not what they are told occasionally.

If you want a better culture, do not start with a new values document. Start with your next ten interactions. Encourage the person who is down. Help the one who is stuck. Build the relationship instead of just running the transaction.

Culture is not your values page. It is how you treat the person having a hard week. So what is the actual culture your team is experiencing, in the small moments, regardless of what the wall says?

The original post, written on LinkedIn in 2019:

"Organizational culture can be changed day by day, not only by the results you achieve but also through your interactions with others. Encouraging a neighbor when they're down, collaborating with a stakeholder who is struggling, and building meaningful two-way relationships with those around you all go a long way to building a stronger culture that will only push your organization further."

Source: Mike's LinkedIn post, 2019 (#organizationalculture #winning #networking).

Keep a human in the loop where being wrong is expensive

Sat, 01 Feb 2025 00:00:00 GMT

The question with AI is not "can it do this." It is "what does it cost when it gets this wrong." The answer tells you exactly where to put a human. Automate the high-confidence cases. Put a person on the rest. In a domain where a wrong answer destroys trust, like money, the model handles what it is sure of and people handle the edges.

We built our accountant product on exactly this principle.

Route by confidence and by the cost of being wrong. The model handles the volume; a human takes the unsure, high-stakes cases.

Automate the easy, review the hard

We built a model to identify the vendor behind a transaction. For most transactions, the model was confident and correct, and we let it run. But some transactions it could not confidently assign, and those are exactly the ones you do not let a machine guess on when the customer is an accountant trusting you with their books.

So we built a human review step for precisely those cases. As I recapped at the time, we did a human review of the transactions that the algorithm could not assign a vendor for. The model did the heavy lifting on the clear cases, which is most of them, and a person handled the ambiguous ones. That is not a failure of the AI. That is the correct design.

Why the cost of being wrong sets the design

Here is the thinking underneath it. In some products, an AI mistake is cheap. A slightly off song recommendation costs you nothing. You can let the model run wide open.

In a financial product, an AI mistake is expensive. Miscategorize someone's transactions and you have not just made an error, you have broken the one thing the product exists to provide, which is trust in the numbers. Once an accountant catches the tool being confidently wrong about their money, they stop trusting all of it, even the parts that were right.

So the cost of a wrong answer is what decides how much autonomy you give the model. Low cost, let it run. High cost, keep a human on the cases where the model is unsure. You are not choosing between AI and people. You are drawing the line based on what an error would actually cost.

Confidence is the dividing line

The practical version of this is to use the model's own confidence to route the work. But "is the model confident" is not a feeling, it is a number. The model produces a confidence score for its answer, and you set a threshold, a bar. Above the bar, the model acts on its own. Below it, the case goes to a human. The threshold is a dial, not a fixed truth. If being wrong is cheap, you can set the bar low and let more through automatically. If being wrong is expensive, like it is with someone's money, you raise the bar so only the model's surest answers go through untouched, and more borderline cases get a human look.

This keeps you from two bad extremes. You do not put a human on everything, which throws away the entire speed advantage of AI. And you do not automate everything, which is how you ship a confident, wrong answer in exactly the place it does the most damage. You let the machine scale the easy decisions and reserve human attention for where it actually matters.

The humans are training the machine

There is one more reason this design is not a compromise. It is a flywheel. Every case a human reviews becomes labeled training data. The vendor the model could not confidently assign gets assigned by a person, and that correct answer feeds back into the model. The next time a similar transaction shows up, the model is a little more likely to clear it on its own, above the threshold, with no human needed.

So the human queue is not a fixed cost you carry forever. It is the exact set of cases the model has not learned yet, and it shrinks as the model learns from the reviews. You start with a conservative threshold and more human review, and over time more of the volume crosses the bar automatically. The people are not just catching errors. They are teaching the system to need them less.

AI does not change the oldest rule of building trustworthy products, it sharpens it. The more it costs to be wrong, the more a human belongs in the loop, and the model should be handling volume, not high-stakes judgment calls it is unsure about.

So before you fully automate something, ask the real question. Not "can AI do this," but "what happens to my customer's trust when it gets this wrong?" Where in your product would an AI mistake be cheap, and where would it be unforgivable?

Buy-in beats brilliance

Sun, 01 Sep 2024 00:00:00 GMT

The best solution in the room loses to the second-best solution that everyone actually believes in. A technically perfect idea with no buy-in does not happen. Trust and communication are not soft add-ons to a good plan. They decide whether the plan ever becomes real.

I first wrote this down on day one of Six Sigma training, years before I built a company. Living it since has only made me more sure of it.

The lesson that stuck from day one

When I started Lean Six Sigma training, I expected it to be about tools and statistics. The most important thing I took from the first day was the opposite. The technical solution is the easy part. Getting people to adopt it is the hard part, and it is the part that decides everything.

A brilliant fix that nobody trusts dies on the shelf. A good-enough fix that the whole team believes in actually ships and actually helps the customer. So the work is not just finding the answer. It is bringing people along, at every level, until the answer is theirs and not just yours.

Why brilliance alone fails

It is tempting, especially for analytical people, to think the best idea should win on merit. In a real organization it does not, and pretending otherwise is how good ideas die.

People do not adopt solutions they do not understand or did not have a hand in. If you drop a perfect plan on a team without earning their belief, they will nod in the meeting and quietly route around it afterward. The plan was right and it still failed, because being right is not the same as being adopted. The gap between the two is filled with trust and communication, or it is not filled at all.

This is why I spend real effort on the why behind a decision, on listening to concerns before pushing a solution, and on making sure the people who have to live with a change had a voice in it. That is not politics. That is the actual mechanism by which ideas become results.

How you earn buy-in

Buy-in is not a vote you call at the end. It is built along the way. You listen first, so people feel understood before you ask them to change. You explain the why, not just the what, so the change makes sense from where they sit. And you give people a real hand in shaping the solution, because people support what they help build.

Do that and adoption stops being a fight. The solution arrives already half-believed, because the people who have to use it were part of making it.

If you have ever watched a clearly correct idea fail while a messier one succeeded, this is usually why. The messier one had buy-in. The correct one did not.

So when you are pushing something you know is right, spend at least as much energy on belief as on the idea itself. Who needs to believe in this for it to actually happen, and have you earned that yet? The answer to that question matters more than how good your solution is.

The original post, written on LinkedIn in 2018:

"I just finished my first day of Six Sigma training. The most important thing I learned in Day 1 is as great and technical as any single innovation is, without the right buy-in it will fail. Even with the great technology we have in 2018, we still need to network and support each other in the main mission of achieving organizational success: contributing solutions to the problems our customers face. It's not enough to have a great solution, everyone at every level has to buy into the solution to make it achieve that end goal of helping the customer. Trust and communication are just as important as the solutions to be identified."

Source: Mike's LinkedIn post, 2018 (#leansixsigma #trust #communication #changemanagement).

The Foogin' Standards: building a culture of excellence

Sun, 01 Sep 2024 00:00:00 GMT

A team only becomes excellent when its standards are three things at once: written down, expected of everyone, and held even when holding them costs you something. I built that into my product team at Talisman, and I gave it a cheeky name. The Foogin' Standards.

The name and the whole idea came from outside my industry, and that was the point.

Four values, held by everyone, expressed as attack, defend, and win. Inspired by Arteta's Arsenal.

Where the name came from

I am an Arsenal fan, and Mikel Arteta is a role model for me in how he builds. When Arteta took over Arsenal in 2019, the club had fallen from its heights. He turned it around by installing a set of standards from day one that everyone had to meet, from the highest earners to the academy kids. The ones who would not meet them, even big stars, were moved on. As The Athletic put it, those who continually fell short were dispensed with, which led to high-profile exits.

"Foogin'" is how the phrase "f***ing standards" sounds in Arteta's Spanish accent. I borrowed it on purpose, because it captured the energy I wanted. Not corporate, not soft, just a clear bar and the will to hold it.

Here is the deeper move, though. I did not get this from a management book. I got it from soccer. Inspiration can and should come from outside your domain. A football club and a software company are not as different as they look. Neither can be carried by one person. Both need a group in sync, holding a standard, to win.

What the standards actually were

I did not just declare "have high standards" and hope. I wrote down what they meant, in plain terms the whole product team could act on.

We had four core values. Focus, so each person knew the single most important thing to do and how they fit into it, and asked when it was not clear. Communication, because over-communicating, when it is concise and relevant, means fewer mistakes and less rework. Attention to detail, because simply doing the job is not doing the job, and a feature that reaches a customer at low quality is a failure for the whole team. And collaboration, because none of us could do our part well without knowing our teammates, their strengths, and their gaps.

Then I made the expectations concrete and non-negotiable. If you see an issue in the live product, you create the ticket. You do not ignore it. If something you are handed is not right, you raise it with your teammate and escalate if needed. You do not ignore it. If you are blocked, you say so immediately, and if you are blocking someone else, you clear it within a day. If you see a teammate's message, you respond within the hour during your working hours. And before you hand a question to someone else, you spend the ten minutes to try to answer it yourself, so you are not passing your cognitive load onto the team.

None of this is fancy. That is the point. Standards that are vague are not standards. They are wishes.

Why they have to apply to everyone, including the leader

The hard part of standards is not writing them. It is holding them when it costs you, especially with your most important people.

This is what I admired most in how Arteta did it. He held the line with stars like Mesut Ozil and Pierre-Emerick Aubameyang, and as one former staffer told The Athletic, winning those battles did not undermine his authority, it enhanced it. The team always came first. A standard that bends for your best player is not a standard. It is a suggestion.

And it runs upward too. Arteta is, by the accounts in that piece, relentless about questioning himself, looking in the mirror, and getting better. I tried to hold myself to the Foogin' Standards before I asked anyone else to. You cannot demand a bar you will not meet yourself.

How we framed it: attack, defend, win

To make it stick, I used the soccer frame directly. We attack by being clear and concise about what we are building, why, how we build it, and how we test it. We defend by meeting every customer requirement, constantly raising the bar for the experience, and never letting our standards drop. And we win by attacking and defending as one team. Excellence is not a moment. It is a hundred small, non-negotiable habits, repeated.

Culture is not the values poster. It is the bar your team actually holds in the small moments, every day, especially when no one is forcing them to. You make that real by writing the standards down, applying them to everyone equally including yourself, and being willing to pay the cost of upholding them.

Arteta gave me the blueprint, and a great name. What outside your own field could give you the blueprint for the team you are trying to build?

From my own "Foogin' Standards" doc, written for the Talisman product team:

"Without standards, clear expectations, and accountability at every level we will never build a product customers love and turn 0s and 1s into functional art that solves real needs... simply doing the job is not doing the job. If a feature gets to customers and isn't quality, it is a sign of failure for the entire product org."

Sources: my own "The Foogin' Standards" document, written for the Talisman product organization. The Arsenal and Arteta details are from James McNicholas, "How Mikel Arteta rebuilt Arsenal in his own image," The Athletic, 2024 (the standards held at every level, the Ozil and Aubameyang exits, Arteta's self-reflection and obsession with improvement). The "Foogin'" name and the attack / defend / win framing are mine, inspired by Arteta.

Be deliberate about data and trust when you adopt AI

Mon, 01 Jul 2024 00:00:00 GMT

Turning on AI features is a one-click decision. Being responsible about what data those features touch is the actual work, and it is the part most teams skip. Especially when customers are trusting you with sensitive information, the question is not just "what can this AI do for us," but "what is it allowed to learn from, and is that okay with the people whose data it is."

I made a specific, deliberate call about this, and it is the kind of call every team adopting AI now has to make.

The setting I almost left on

We were using a tool with AI features, and like a lot of these tools, it had an option to train its model on the content we fed it. That setting is easy to leave on without thinking, because the feature works either way and nobody is forcing you to look.

I looked, and I turned it off. As I noted at the time, I turned off the content training so it would not use any of our team's files to train the AI model, while leaving the actual AI features on. The reasoning was straightforward. We could get the benefit of the AI features without handing our and our customers' content over to train someone else's model. That tradeoff was worth making, and it was not the default.

Why this is the real work of adopting AI

Anybody can switch on an AI feature. The valuable judgment is in the boundaries. What data does it see? What does it retain? What does it train on? Who would be upset if they knew?

When your customers are trusting you with sensitive information, those questions are not optional or paranoid. They are the difference between adopting AI responsibly and quietly creating a problem you will have to explain later. A single careless default, content training left on, could mean customer data flowing somewhere it should never go. The feature still works. The trust quietly erodes, and you might not find out until it is a headline.

So the discipline is to treat every AI integration as a data decision, not just a feature decision. Read the settings. Find the training toggle. Decide on purpose what your data and your customers' data are allowed to be used for.

Trust is the asset you are protecting

This connects to something I believe about products in general. Especially early, you are not just selling features, you are earning trust. AI raises the stakes on that, because the tools are hungry for data and the defaults are usually set in the vendor's favor, not your customer's.

Being deliberate here is how you keep the trust you worked hard to build. It is unglamorous. Nobody sees the training toggle you turned off. But it is exactly the kind of quiet, responsible decision that separates a team that respects its customers from one that just ships fast and hopes nobody asks.

Adopting AI is easy. Adopting it responsibly is a series of small, deliberate decisions about data that nobody will praise you for and everybody would blame you for getting wrong.

So when you turn on the next AI feature, do not stop at "does it work." Ask what it touches and what it learns from, and decide on purpose. What is the default setting in your AI tools that you have never actually checked?

Ask the dumb question

Sat, 01 Jun 2024 00:00:00 GMT

The fastest way to lose an engineer's trust is to fake technical understanding. The fastest way to earn it is to ask the naive question openly and defer to their judgment on their craft. As a PM, your value is not pretending to know how it works. It is being clear about what needs to happen and humble about how.

I ask dumb questions on purpose, and it has served me well.

Faking it is expensive

When a non-engineer nods along to something they do not actually understand, two bad things happen. The conversation moves forward on a misunderstanding, which surfaces later as wasted work. And the engineers clock it immediately, because they always can, which quietly tells them your input cannot be trusted.

So I do the opposite. I name the gap out loud. I will literally open with "dumb question, but," and then ask the thing I do not understand. For example, when we were dealing with bugs, I asked plainly, might be a dumb question, but if the bugs exist in production, wouldn't they also exist in staging, so shouldn't we fix them there too? It is a simple question. Asking it openly got us to a real answer faster than pretending I already knew would have.

The naive question is not a weakness. It is the shortest path to a shared, accurate understanding, and engineers respect it far more than confident nonsense.

Defer on their craft

The other half of this is knowing where my judgment ends and theirs begins.

When we discussed having a teammate peer review another engineer's work, I framed it as a good thing and added something I genuinely believe. It is always good to have peer review, because looking at the same thing all the time is an easy way to miss something, and that happens to me all the time. But then I made the boundary explicit. The engineer might have a different opinion from a technical perspective, and on that ground, his view should carry more weight than mine.

That is the posture. I own the what and the why, the problem we are solving and why it matters. They own the how. When we disagree on the how, I do not pull rank, because it is not my rank to pull. Deferring to their expertise on their craft is not weakness either. It is respect, and it is usually correct.

Why humility is the stronger position

It can feel safer to project authority, especially as a PM who does not write the code. In reality, humility is the stronger position with a technical team.

Admitting you do not know something invites the expert to teach you, which makes the decision better and makes them feel valued. Pretending you know shuts that down and makes the decision worse. Over time, the PM who asks good naive questions and defers on craft earns more real influence than the one who postures, because engineers will actually tell them the truth.

This connects to a bigger habit of mine. When a domain is not yours, you do not reason it out alone. You find the person who lives in it and ask. With engineers, that person is sitting right next to you.

Your job working with engineers is not to out-engineer them. It is to be crystal clear about the goal and genuinely humble about the implementation, and to make it safe for them to correct you.

So the next time you are tempted to nod along to something technical you do not fully follow, try the other thing. Say "this might be a dumb question," and ask it. What is the question you have been afraid to look dumb asking? That is probably the one worth asking out loud.

Your lived experience is a product superpower

Sat, 01 Jun 2024 00:00:00 GMT

The best product insight often does not come from a spreadsheet or a competitor teardown. It comes from your own life. The experiences that seem unrelated to your job are frequently the exact thing that lets you see a customer problem nobody else on the team can see. Tapping into your full lived experience is a real product advantage, and most teams leave it on the table.

This is something I think about a lot, and there is one story that made it click for me.

The Windstar Moms

Before I started my company, I genuinely wanted to go get a master's in organizational behavior. I am fascinated by how you uncover each person's full potential to get the best outcomes for a team, whether that is a workplace, a sports team, or a marching band. And the thing I kept coming back to is that uncovering someone's potential means letting them draw on one hundred percent of their life experience, not just the part listed on their resume.

My favorite example came from a story about Ford. Back in 2000, only a small fraction of automotive engineers were women. Ford did something notable. They put a team of women engineers together to make the Windstar minivan better for its core customer, mothers with children. The team became known as the Windstar Moms.

They drew on their actual lives as mothers and changed the product in ways a different team never would have thought of. Thinner steering wheels. Rectangular cup holders sized for juice boxes. And a larger gas tank, pushed hard by one engineer who was also a mom, because she hated nothing more than refueling with crying babies in the car. Her life as a mother informed her work as an engineer, and the product got dramatically better as a result.

That is the whole idea in one example. The insight did not come from market research. It came from lived experience that the engineers were finally allowed, and encouraged, to bring to work.

Why teams leave this on the table

Most workplaces quietly ask people to bring only the professional slice of themselves. You are an engineer, or a marketer, or a PM, and your job is the narrow function on your title. The rest of your life is supposed to stay home.

That is a waste, and it is often the difference between a product that technically works and one that customers love. The person on your team who grew up in the neighborhood you are selling into, or who has lived the exact problem you are solving, is carrying insight that no amount of research will replicate. If your culture does not invite that in, you never get it.

So part of building a great product team is making it safe and expected for people to say, "here is how my own life tells me this is wrong," and to be taken seriously when they do.

How I try to use this

One of the things I care about most in how we build is encouraging the team to draw on their real experiences to solve real customer problems. Not just their training, their lives. The goal is to build products that are genuinely useful and genuinely good to use, and the fastest path to that is people who can feel the customer's problem because they have lived some version of it themselves.

When you do this, you get two things at once. You build a better product, because you have insight competitors cannot buy. And you build more fulfilling work, because people get to bring their whole selves and see their real lives matter in what they create. Those two things reinforce each other.

I never did get that org-behavior master's, at least not yet. Instead I got to roll up my sleeves and build a company where these ideas are not theory. They are how we work.

You are not just your job title. The most valuable thing you bring to a product might be the part of your life that has nothing to do with your role on paper.

So the next time you are stuck on a customer problem, do not only open the research. Ask who on your team has lived this, and what their life is trying to tell you. What is one thing from your own life, outside of work, that quietly makes you better at the work?

From the original post, written on LinkedIn in 2024:

"Before starting Talisman, I wanted to go to Wharton and pursue a master's degree in organizational behavior. I was (and am) fascinated by the idea of uncovering every team member's full potential... how does a completely unrelated experience in my life help me with my work today?

Back in 2000, only 8.5% of engineers were women. It was notable then that Ford put 30 women engineers on the same team to make Windstar minivans more user-friendly for their core customer base: women with children... One of the Windstar Moms, Cindy Hodges, a mechanical engineer, pushed especially hard for the idea of a larger gas tank. She said, 'There was nothing I hated more than refueling with crying babies.'... Her experience as a mother informed her work as an engineer and 10x'd her product as a result.

We encourage and inspire our team to draw from their life experiences to solve real customer problems as they build products. Just like the Windstar Moms did."

Source: Mike's LinkedIn post, 2024. The Windstar Moms and Cindy Hodges details are as Mike recounted them in that post.

A good spec passes one test

Sat, 01 Jul 2023 00:00:00 GMT

Here is the only test a spec or a ticket needs to pass. Could a teammate pick it up and build it without coming back to ask you what you meant? If yes, it is done. If no, it is not, no matter how much is written on it.

I use this as a hard line, and it has saved us a lot of wasted work.

The standard I actually used

When I reviewed a teammate's tickets one week, my feedback was blunt and it captured the whole idea. There was a lot of work needed, I told him, to get this to a place where I could take the ticket and actually work it myself.

That is the bar. Not "is there text in the ticket." Not "does it look thorough." The bar is whether someone other than the author could execute it cleanly. If I, reading it cold, could not pick it up and build it without a follow up conversation, then the ticket was not finished. It was a placeholder pretending to be a spec.

Why the ambiguity has to die up front

Every spec has some ambiguity in it. The only question is when you resolve it.

If you resolve it up front, in the writing, it costs a little time and everyone moves fast afterward. If you leave it in, the builder hits it in the middle of building, at the worst possible moment, and has to stop and guess or chase you down. Multiply that by a team and you get a product full of small guesses, each one a little off from what was intended.

So I wrote requirements to absorb the ambiguity before anyone started. The job the user was doing. Where the thing lived on the screen. How it behaved. The logic, spelled out step by step. The point was never to sound thorough. The point was that the next person never had to fill in a blank I left them.

How to write one that passes

The routine is straightforward.

Start with the user's job, in their words, so the builder knows what success looks like from the user's side. Then the specifics. Where it appears. How it behaves in the normal case. What happens in the edge cases, like an empty state or an error. The acceptance criteria, written so they can be checked as true or false.

Then do the one thing most people skip. Read it back as the builder, not as the author. You wrote it, so you know all the things you left unsaid. The builder does not. Read it as someone who knows nothing beyond the page, and you will spot the gaps fast.

The honest cost

This is more work for the person writing the spec, and that is exactly why people avoid it. It is easier to write a vague ticket and answer questions later. It feels faster.

It is not faster. It just moves the work from one careful hour of yours to many interrupted hours across the team, plus the rework when someone guesses wrong. Front loading the clarity is the cheaper path. It only looks more expensive because the cost is visible and lands on you.

A spec is not a description of what you want. It is a set of instructions precise enough that someone else can act on them without you in the room. That is a higher bar than most tickets clear, and it is the bar worth holding.

Before you hand off your next ticket, read it once as the person who has to build it. Could they finish it without a single question for you? If not, you are not done writing yet.

Speed is a form of respect

Sat, 01 Jul 2023 00:00:00 GMT

How fast you respond to a customer tells them how much you value them. Often it says more than the fix itself. On a small team, treating a customer's problem as urgent is an advantage you can simply choose to have, and most companies do not choose it.

Here is a morning that made that real for me.

A bug at 6:33am

One of our European customers found a bug and reported it in Slack at 6:33am. Marking a possible subscription as "Not A Subscription" was not removing it from the review widget. Small bug, but it made the product look like it was not listening to them.

I saw it and replied at 6:35am. Two minutes. I did not have a fix yet, and I did not pretend to. I just said what was true.

"Thanks for raising this to our attention. We will review this and circle back here shortly!"

The customer wrote back one minute later. "Thank you, Mike!"

That tiny exchange did something important before any code was touched. It told the customer they were heard. Their problem was now our problem, and they did not have to wonder if it had disappeared into a void.

[SCREENSHOT 1: the Slack thread showing the customer's 6:33am bug report and Mike's 6:35am reply. Caption: "The bug report at 6:33am, and the reply two minutes later. The fix had not started yet. The acknowledgment still mattered."]

What happened over the next few hours

The acknowledgment was the start, not the end. Behind it, the team moved fast.

Within two minutes of the report I had also flagged it to our CTO. By 6:45am I had recreated the bug myself, so the engineer was not chasing a vague description but a confirmed, reproducible problem. A teammate was producing a fix shortly after. Our product lead jumped in around 6:55am to help. By 11am the fix was tested and ready, and we went back to the customer to ask them to confirm it on their end.

[SCREENSHOT 2: the Slack thread continuing, with the team confirming the bug was found, root cause underway, and the 11:43am message asking the customer to verify the fix. Caption: "From report to tested fix in under five hours, with the customer kept in the loop the whole way."]

So in one morning, a customer's report became a reproduced bug, a fix, a test, and a verification request. The customer never had to follow up. We followed up with them.

Why speed is respect, not just service

It is easy to frame fast response as good customer service. I think it is bigger than that. Speed is a signal of respect.

When you reply in two minutes, you are telling the customer their time matters as much as yours. When you let a report sit for two days, you are telling them the opposite, no matter how nice the eventual reply is. The delay is the message. People feel it.

And here is the part founders miss. Speed is one of the few advantages a small team has for free. We could not outspend anyone. But we could out care them, and caring shows up most clearly in how fast you move when a customer raises their hand. A big company routes that bug through a queue. We answered it in person, in two minutes, at 6:35 in the morning.

It only works if the whole team is wired for it

None of this happens because of one fast reply. It happens because the team is built to move. My two minute acknowledgment was worth something only because I could flag it to the CTO immediately, recreate it within minutes, and trust that an engineer and a product lead would jump on it without being chased.

That is the operator's job in a moment like this. Catch it, confirm it, route it, and keep the customer informed at every step, so the speed the customer feels is backed by real motion underneath. A fast reply with nothing behind it is just a nicer way to make someone wait.

[SCREENSHOT 3: Chiko's LinkedIn post recapping the timeline and the "customer obsessed" ethos. Caption: "Our CEO's write-up of the same morning. Customer obsession is not a slogan you put in a deck. It is what you do at 6:35am."]

A customer found a bug at 6:33am. By 6:35 we had replied, and by 11 it was fixed. I am as proud of the two minute reply as I am of the fix, because the reply is what told the customer they mattered.

If you want customers to trust you, do not wait until you have the answer to respond. Respond first, then go solve it fast. Speed is the clearest way to show someone you respect them. How long does a customer of yours currently wait just to hear that you heard them?

Spec the outcome, not the story

Tue, 01 Nov 2022 00:00:00 GMT

Hand engineers testable acceptance criteria, not a loose narrative of what you had in mind. A clear "given this, when that, then this" beats a paragraph of intent every time. Engineers do not need your story. They need to know exactly what is true when the work is done.

This was a deliberate change I made to how we wrote tickets.

Acceptance criteria over narrative, with big tickets structured as a shell plus subissues. The test: could someone build it without asking you a question?

From scenarios to criteria

Early on, our tickets read like little stories. A description of a situation, some context, a general sense of what should happen. It felt thorough. But a story leaves room for interpretation, and interpretation is where a build drifts from what you meant.

So I set a standing task to fix it. We rewrote each ticket to show acceptance criteria, not scenarios. Concretely, that meant the "given, when, then" format. Given the user is on this page, when they click this, then this specific thing happens. Each line is a condition you can check as true or false. There is no room left to guess, because the finished state is written as a set of facts, not a mood.

The difference matters most at the end. With a narrative ticket, "is it done?" is a judgment call. With acceptance criteria, done is simply whether every line is true. The ticket grades itself.

Structure the big ones as shells

For larger pieces of work, I used a structure that kept this clean. The parent ticket became a shell. It held the user story and the high level acceptance criteria, and it pointed to subissues that carried the detail for each step.

That way the parent answered "what is this and what does success look like," and each subissue answered "here is exactly what to build for this slice." An engineer could see the whole shape from the parent and get the precise instructions from the subissue. Nothing important lived only in someone's memory or a Slack thread.

How this differs from just writing a clear spec

I have a related rule that a good spec passes one test: could someone build it without asking you a question. This is the companion to that, and it is more specific. That rule is about clarity in general. This one is about format.

You can write a clear, well intentioned paragraph that still fails an engineer, because a paragraph describes and acceptance criteria verify. The format itself does work for you. Writing "given, when, then" forces you to think in concrete, checkable outcomes, which catches the gaps a narrative would have glossed over. The structure is not bureaucracy. It is a thinking tool that happens to also be the cleanest handoff.

When you hand work to an engineer, you are really handing them a definition of done. Make that definition something they can check, not something they have to interpret.

Write the outcome as testable criteria. Use the parent ticket for the story and the why, and let the criteria carry the what. Before you hand off your next ticket, look at it and ask, is the finished state here a set of facts I could check off, or a story someone has to read my mind to complete?

Quality is a process, not a vibe

Sat, 01 Oct 2022 00:00:00 GMT

Quality is not a feeling you have about your product. It is a bar you write down before you build, and then refuse to ship below. Teams that treat quality as a vibe ship inconsistent work. Teams that treat it as a written standard ship the same high bar every time.

I am strict about this, and the strictness is the point.

Write the finish line before the race

Before our first launch, I pinned a Definition of Done where the whole team could see it. Not a feeling, a list. Concrete statements written from the user's side. As a user, I can log into the production version, connect my bank or card, and see my spend. Each line was something you could check as true or not true.

That pinned doc did something important. It turned "are we ready?" from an argument into a checklist. Nobody had to debate whether we were done, because done was written down in advance. You either met the bar or you did not.

This is the core of it. Quality becomes a process the moment you define the finish line before you start running. Without that, every release turns into a judgment call, and judgment calls under deadline pressure always drift downward.

The bar applies to every handoff, not just the final ship

I held the same line earlier in the chain, not just at launch.

On design, my rule was simple. We would not attach a design to a development ticket unless it was exact. As I said to the team, we will not attach them to a story unless they are picture perfect and are exactly what we need. When a designer was handing over work that was not ready, I named it plainly. We needed things designed so they were truly pixel perfect and ready for development.

That is not me being difficult. A blurry design handed to a developer becomes a guess, and a guess becomes a bug, and a bug becomes a worse user experience. The cost of a low bar does not disappear. It just moves downstream and gets bigger. Catching it at the handoff is the cheapest place to catch it.

We backed it with rhythm too. Daily QA, testing in staging and in production, logging bugs the moment we found them. Quality was not a final inspection. It was something we did every day.

The bar is scoped, not infinite

Here is the part that keeps this from turning into perfectionism. A Definition of Done is scoped to the thing you are shipping, not to some ideal version that never ends.

My pinned standard was the Definition of Done for that first launch. It was not a wish list of everything the product could ever be. It was the specific, finite set of things that had to be true for this release to count. That scoping is what makes it usable. An infinite bar paralyzes you. A clear, finite bar ships you.

So the discipline is two sided. High enough that you are proud of what goes out, and bounded enough that it actually goes out. You write down what done means for this release, you hit all of it, and you do not let "done" quietly expand while the deadline sits still.

If your team argues about whether something is ready, you do not have a quality problem. You have a definition problem. Nobody wrote down what good looks like, so everyone is using their own private version.

Fix it upstream. Write the Definition of Done before you build. Hold the bar at every handoff, not just the last one. Keep it scoped to the release in front of you. Quality stops being a feeling you argue about and becomes a line everyone can see.

What does done actually mean for the thing your team is shipping this week? If you cannot point to where that is written, that is the first thing to fix.

How to name a product

Tue, 01 Feb 2022 00:00:00 GMT

The best product names do not come from a thesaurus or a domain availability checker. They come from finding the oldest, most human version of the problem you solve, and naming that. Start from the timeless problem, not from a list of cool words.

When we were naming the company, I kept pulling the team back to that idea instead of letting us brainstorm pretty words.

Start with the oldest version of the problem

My instinct during the naming process was not to ask what sounds good. It was to ask what we actually do, at the most basic human level. As I put it to the team, the problem we are solving is not a genuinely new one. It is one that has existed with humans for a long time. There is some way to break it down to the oldest version of the problem, and from there we can probably find a single word that describes it.

That reframe changes the whole exercise. You stop searching for clever and start searching for true. A name built on the timeless version of your problem will still make sense in five years, because the underlying problem is not going anywhere.

Name the core metaphor, not the feature

Once you are anchored on the real problem, you look for the metaphor at the center of it.

So I tested words against what we fundamentally were. I was thinking about words like door, because we were the gateway from inside a company to the outside world of its tools. Or gate, the same idea. Or center and middle, because we sat at the middle of everything a company runs on. Later we looked at Mimoto, which means identity in Japanese, because identity is at the center of everything. Everything you get access to flows through who you are.

Notice what those candidates have in common. None of them describe a feature. They describe our place in the customer's world. A feature name ages out the moment the feature changes. A name built on your role in the customer's life lasts.

How we actually landed on Talisman

Here is the part the framework leaves out. The winning name did not come from a spreadsheet of metaphors. It came from a long meeting where Chiko, Dan, and I were stuck. We were moving off our old name, Enkrypt, and we knew what we wanted the new one to do. We wanted something that meant something real to a business, something that would make a company feel like using us gave them powers.

I brought up talismans. Growing up in the early 2000s, I watched a cartoon on Kids WB called Jackie Chan Adventures, and in it there were talismans, and each one carried its own distinct power. That image stuck with me, and it fit exactly what we were trying to be. A customer would use Talisman to give their business powers. We even loved that it could scale into how we treated our own team, handing out talismans as people hit milestones and achievements.

What made it work was not just that it was a fun reference. It was that it passed the test I started this essay with. A talisman is one of the oldest ideas humans have, an object you carry that gives you power or protection. So the name came from a childhood cartoon, but it landed because it tapped the most ancient version of what we did. It was personal and specific to me, and at the same time it scaled to a real meaning for any business. That combination, something that is uniquely yours but means something universal, is what a great name is made of.

Why this beats chasing clever

It is tempting to name a product the way you would pick a clever tweet. Something punchy, something with an available domain. The problem is that clever-for-its-own-sake usually says nothing about what you do, so you spend years teaching the market what the name means.

A name rooted in the oldest version of the problem does some of that teaching for you. It carries meaning. When the metaphor is right, the name quietly reinforces what you are every time someone says it. That is a real advantage you get for free, but only if you earned it by starting from the problem instead of the wordplay.

The honest caveat

This is not a clean formula, and naming is partly taste. You will land on a metaphor that is right but already taken, or right in English but strange in another language. We ran into exactly that, where a word we liked translated oddly across markets. That is normal. The point of starting from the oldest version of the problem is not that it hands you the perfect word instantly. It is that it gives you a true north, so every candidate gets judged against what you actually are, not against what sounds nice in a meeting.

A name is not decoration. It is the shortest possible description of your place in the customer's world, and you get to choose whether that description is meaningful or empty.

So do not start a naming session by listing cool words. Start by asking what the oldest, most human version of your problem is, and what single word sits at the center of it. Build outward from there. Ours came from a cartoon I loved as a kid, and it worked because underneath the cartoon was an idea as old as people. What is the timeless problem underneath the thing you are building right now?