In 2006, I shipped my first product. The whole process back then ran on the assumption that building was the expensive part. For most of my career, that was true.
And the assumption generally held up, despite all of the wild shifts of the last 20 years: Mobile rewiring how we designed software and built teams. The cloud rewiring how we shipped. SaaS subscription rewiring how we sold and renewed customers. I remember groping around in the dark as we built the HipChat Apple Watch app in 2015! We didn’t even know how people would use Watch apps (we basically built a mini-mobile app).
And of course, pour one out for the shifts that had less staying power — anyone remember the time sunk into Silverlight or Flash? Feels like a million years ago.
Each shift felt huge at the time, and each one, in hindsight, was a change to the how — new tools, new delivery, same job underneath. I adapted my toolkit and kept moving.
But this is vastly different. The size and speed of change is unprecedented. So my learning and adapting has sped up.
After spending the past 18 months shipping inside top-tier AI-native teams in SaaS, here are three things I used to hold sacred that I’ve changed my mind on.
1 Staff to the work, not to ratios.
My hiring used to run on ratios. Remember those days? A PM for X engineers, a designer for Y PMs, a triad on every team, and each team had an identity, a motto, and a t-shirt design. Someone would quit and the whole triad was out of whack, and the team would grind to a halt because there was so little skill overlap. We’d realized there was a greater priority, but the team structures were so rigid and roadmaps so set that reaction time was abysmal.
I’ve thrown the ratios out.
Not because everyone’s a “builder” now, but because the work is more nuanced than a formula (it always was, I suppose), and the tools are more capable. Go deep where the work needs a specific craft. But an engineer with real product chops can carry a team. So can a designer who’s comfortable shipping the MVP. Every seat you add brings more coordination and hand-offs. Teams are able to stay much smaller and fluid. Follow the work.
Which asks something different of leaders than 5-10 years ago — to be much closer, more in the details.
2 Good top-down is good.
Hire smart, get out of the way. Cause teams hated drive-by dive bombs, and leaders didn’t have the time or ability to stay proactively engaged.
Perhaps well-intentioned, but as I look back, some of it, honestly, was that going deep was expensive — reading the code, staying across multiple teams, sitting in the research all took time I didn’t have, so I stayed at the high level and called it team “autonomy.”
That excuse is gone. Getting deep got cheap. Now I’m back in it, in the same way I was “in it” in my early career as an IC. And so is every product leader I know. Trading the ceremony we’d built up for real time with the team, with the code, with customers. And when a leader is genuinely that deep, top-down stops being a bottleneck. There are no drive-by dive bombs when you’re just…in it.
Cancel the meetings, get into it with the team. That’s not getting in the way. It’s clearing it.
The age-old Alignment / Autonomy cartoon as a concept still holds. Just realizing that I was lazy about both sides.
3 Build to think.
Building used to be the expensive thing you did after you understood the problem. It cost so much that we guarded it — de-risked everything first, researched until we were sure, then finally the teams would build.
That’s inverted. Now the fastest way to understand a problem is often to build a rough version with customers. The build can be a tool to get to clarity.
Just this week: I built a flow we'd talked with customers about and whiteboarded. Opened the PR, we started using it, and the friction was immediate — no brainstorm or mock up would have revealed it, either. Just had to use it. We changed course that same day, got feedback on the winning pieces, and scrapped the rest. That would have taken weeks.
Flannery O’Connor is often credited with saying:
I write because I don't know what I think until I read what I say.
Writing was the primary tool we had to find out what we were thinking. Getting to clarity on the what, why, how we know when we succeed. That is still true. Full stop. Writing still matters here — it always will.
And, dopamine-induced loops of prompt-slop don’t count as writing.
Clarity is the whole game, and crisp writing is still the cleanest evidence of clear thinking (even if the primary consumer of your writing is an agent).
But writing isn’t the only way to get to clarity anymore. Prototyping was always important, but it took time, and meant not doing something else. Now, it’s 10x faster than it used to be, and allows you to think through complicated user experience and workflow nuances earlier, with customers. Writing, building — same goal of getting to clarity, faster.
Amazing to think about how much we — I — believed was built on top of the (former) truth that building was the expensive part. The ratios. The role delineations. The “Go Big” hiring campaigns.
Then the floor moved!
I’ve never been more curious about what’s next, and how we continue to question how we do product work. Here’s to the next 20!