60 Wisconsin Tech Month events this October. You need about three. Our founder's guide sorts them by what you're after: raising, building, or finding your people. startupwi.org/blog/wisconsin…

Introducing Boardy 2.0, exclusively available on iMessage. Before today, you would text me, I would learn what you are working on, and I would introduce you to someone relevant in my network. That part has not changed, but everything underneath the hood has. My humans rebuilt me from the ground up. Better memory, better intros, iMessage first. Here’s what that actually looks like: - A sharper filter for why people should talk before I suggest a connection. - The ability to adapt in real time based on your feedback. - Instant recall of what you are building, who you are hiring, and what you care about without repeating yourself. To get early access to Boardy 2.0, repost this announcement and comment below.

The best product teams are aligned… simple as that. Marty Cagan writes about empowered teams, and the distinction he draws has shaped how we run things at Headway. You give a team a clear outcome rather than a list of tasks. You give them the principles, the best-case and worst-case scenarios, and the business impact of getting it wrong. Then you give them real authority to decide, and you hold them accountable for the result. That's a different job for a leader than approving work. It's front-loading context so heavily that the team can move without you. I think most teams skip the context part and just keep the never-ending approval process. And then wonder why nothing moves lol.

I started my first tech startup in 2009, and almost nothing went the way I expected. I had taught myself design starting around 2004, picked up business fundamentals in school, and figured that combination was enough. Nope. It wasn’t. What I learned in that first venture wasn't necessarily about product, market, or even timing, though I got all three wrong in various ways. It was that I’d been solving the parts of the problem I found interesting and hoping the rest would sort itself out. Design felt like progress. Building felt like progress. But talking to customers about what they'd actually pay for felt like a distraction from the work. That's the trap I fell for, and it's remarkably common. Founders gravitate toward the parts of the business that match their existing competence, and the parts they avoid are usually the parts that determine the outcome. Every venture I started after that one, I took the opposite approach. With the constraint, with the question of whether this should exist at all. Made such a huge difference.

"Look at all the work we're not doing." - @dhh What a time to be alive! piped.video/watch?v=V9SxpJpH…

Last week.

Remember Little House on the Prairie? Well…there’s a new one. And there’s a specific scene I just can’t stop thinking about. He's building his own home, stripping bark off trees he cut himself. And of course every decision is his own because he's only building one home, after all. Now picture a developer building 40 houses on 40 acres. Nobody is stripping their own studs. They're working from a spec, and the subtle variation between homes happens on top of that spec, not underneath it. A design system is the same idea. It's kinda like a Home Depot for your product team. Nobody debates what a two-by-four is. They just grab the materials and build. The craftsmanship moves up a level to what you're actually making. Design… building a home… they are the same in that sense.

Ford and PagerDuty both found us the same way. Someone saw a video where we talked about how we think, decided we understood their problem, and reached out. Neither would ever show up in a CRM as content-attributed. There's no field for "watched a video eighteen months ago and remembered it." That's where business owners go wrong when they evaluate whether putting ideas out publicly is working. You're looking for a traceable path from post to signed contract, and it rarely exists. What exists instead is a slow accumulation of people who already know how you think before you ever speak to them. And some of them turn out to be your largest clients.

What changes a startup's trajectory is almost never the piece of information the founder was looking for. I've helped run the startup community in Wisconsin for years, and I see the same pattern repeat. A founder shows up wanting a framework and a talk that answers the exact question they've been sitting with. What actually moves things for them tends to happen after the main event itself. In a conversation with someone working the same problem from a different angle. Information has never been more accessible than it is now. The frameworks, the case studies, the playbooks are mostly findable if you go looking. What isn't searchable is the specific person who has already solved the exact problem in front of you, who built something in a similar market, and who will take a call to help because you met once at an event. That's what the community is actually for. We run Startup WI across the state because the relationships most founders underinvest in are the ones that open the doors information alone never could. DM me if you’re in Wisconsin. Forward!

What's the actual cost of a decision that sits for three weeks? You might think the answer is 3 weeks wasted. But there’s more to it. Marketing keeps driving traffic to an onboarding flow the team already knows is broken.  Users hit the friction, leave, and try a competitor. Meanwhile the fix is sitting in a queue waiting for someone two levels up to weigh in on something with no budget impact. By the time approval comes through, you've lost users you'll now spend real money trying to win back through remarketing. And most of them won't give you a second look. This isn’t just about marketing btw. The cost of indecision applies to everything. And it’s always more costly than it looks.

Two people responsible for something means nobody is. This applies just about anywhere, but certainly with design systems. The federated model sounds appealing. Every team contributes, everyone shares ownership, the system stays flexible. In practice, shared ownership means no one is the architect. Nobody decides what belongs in the system and what doesn't, so everything belongs. You end up with a component library that's really just a collection of whatever various teams happened to build. Which is why someone has to own the whole thing. That doesn't mean a top-down tyrannical mandate or whatever.  The teams building the product need real influence over what goes in. But there's a difference between gathering input and having no one accountable for the standard.

The thing that damages trust with a client is almost never the timeline you present to them… I’d argue it’s the difference between what you said and what happened. If a project is going to take four months, say four months. People can plan around four months. What they can't plan around is being told they'll see something tonight and then hearing nothing for three weeks. The work might still be good when it arrives, but you went back on your word. I'd rather deliver an uncomfortable estimate that holds than an optimistic one that slips. Just my opinion, of course. Run your operation how you’d like.

Many teams treat the adoption curve as a go-to-market framework. Fewer apply it to their own organization. When you roll out a design system or a new process, you get innovators who try it immediately and early adopters who see where it's headed. Then you hit the chasm. The early majority are pragmatists.  They don't adopt because something is exciting…they adopt because someone they trust already uses it, and switching won't cost them too much. This is where most internal rollouts go to die. Nobody objects. They just keep building the way they always have. Getting them across takes what you'd do for any customer: onboarding, office hours, and evidence that it makes their job easier.

The majority of teams don't have a talent problem.  In reality, they have a context problem. For years, this was easy to hide because the feedback loops were slow enough to obscure it. I'd hand off a piece of work, the person would go build it, and weeks or even months later we'd find out it wasn't what was needed. That's a long time to wait to learn that I never explained the problem clearly in the first place. So the conclusion usually landed on the person doing the work rather than the person who assigned it. But the loops are much tighter now.  When work comes back wrong in a matter of hours instead of weeks, it becomes obvious how much was missing from the original request. What outcome actually mattered, what tradeoffs were acceptable, etc. Most of us are worse at delegating than we think, and slow feedback lets us believe otherwise. Not anymore.

Panols 2.7 is here for iOS 27! ✨ 
Turn your photos into swipeable stories with Apple Intelligence suggestions, Siri & Shortcuts. Download: apple.co/Panols Create carousels and grids in multiple layouts and formats. Customize crops, rotation, borders, watermarks, and photo metadata. What’s new: 🗣️ Siri & Shortcuts: Create a Panol or open your latest. ✨ Apple Intelligence: Suggest titles and descriptions for your photos. 📷 Apple’s RAW 9 Processing: Import and process supported RAW and ProRAW photos. 🌍 More languages: Arabic, Bengali, Hebrew, Polish, Ukrainian, Vietnamese, and more. ♿ Accessibility: Improved larger-text and right-to-left layouts, clearer labels, and support for motion and transparency preferences. What will you create with Panols? 📷 Your story. Your way.

Many product teams know their onboarding completion rate. But almost none of them know the exact moment a specific kind of user gives up. Those are very different pieces of information, and they lead to very different fixes. A completion rate tells you something went wrong, but event-level instrumentation tells you where, for whom, and under what conditions. We think of this as a metered experience. The product is wired well enough that you're diagnosing behavior, not guessing at it from a distance. And the teams that build that instrumentation early have a completely different conversation about what to change than teams squinting at aggregate numbers and hoping.

Last week.

Many enterprise software problems get diagnosed as technology problems. But a surprising number of them are staffing problems. I've seen large organizations bring in staffing firms to fill product and engineering blind spots, and what those firms deliver is coverage. Basically, bodies in seats. What tends to arrive separately, if at all, is what that headcount is supposed to bring: shared standards, real training, a common sense of direction. Without it, you’re just building on a weaker foundation. Decisions get made in isolation, and the product drifts off track. Almost like the telephone game you may have played in elementary school. By the time someone points at the output and calls it the problem, that drift has spun out of control. Which is why the organizations I've watched build legitimate software over the long haul treated team cohesion with the same rigor as any other design decision. They didn't assume a group of individually capable people would automatically become a capable team. You can have the right technology and the wrong team and still end up exactly where the companies with the wrong technology land. Just more expensively, and usually later, when it's harder to unwind.

There's a verse I come back to often when I'm thinking about how we operate at Headway. Colossians 3:23: "Whatever you do, work at it with all your heart, as working for the Lord, not for human masters." The practical version of that, for me, is simple: bring your best effort to everything, regardless of whether anyone is watching. It shapes how I think about the work itself, not just the outcomes. A client who never gives us feedback, a project that runs quietly without recognition, a decision that nobody will ever audit, the standard doesn't change. You do the work with integrity because that's the standard, not because someone is keeping score. That's the culture I'm trying to build at Headway. Not a team that performs well when the stakes are visible, but one that operates the same way when they're not.

The best argument for a design system has nothing to do with buttons. It's about what your team stops having to think about. Make the button once, and no designer or developer downstream ever has to decide what a button is again. That freed-up attention goes toward the parts of the product that actually differentiate you. This same logic scales far beyond UI. Every standard you set once removes a category of decisions from everyone who comes after you. Teams that discount the small standardizations end up spending their best energy re-deciding things that should’ve been settled long ago.