Long before we have a roadmap, we have to build and agree on the system the team runs on: the way work gets decided, written down, built, tested, and shipped. It should feel invisible when it's working, which is exactly why so many people skip over it, or dismiss it entirely as unimportant, or even a waste of time. But agreeing on how we work is the whole game, especially now, when building is easier than it's ever been, that agreement matters more than ever.
I've worked with all kinds of teams with all kinds of preferences for how we work. The most successful teams I've been a part of understood that spending the time to agree, iterate, and improve how we work is one of the most important indicators of long-term success.
And when I say process or "how we work" I don't mean bureaucracy or process for process' sake. The goal is just enough structure to move fast without anyone being confused on how an idea becomes a shipped product. Structure creates speed, and confusion slows teams down and causes rework. Good team process should feel like breathing: from communication, the way we move through the day and work together, if done right it should feel automatic for everyone on the team.
HVAC.com: teaching a technology company to work like one
HVAC.com was acquired by Trane Technologies. HVAC.com's parent company, Magenta Tech, had been contracted to build digital experiences for Trane, and at some point it was cheaper to bring us in-house than to keep paying an outside shop. A few years before, Trane had added "Technologies" to its name, a signal it was serious about technology.
Our stakeholders were used to outside vendors that would abstract the process away and charge you for the privilege. In-house product development was new to them. There was no shared template for annual planning and no agreed way to take everything we wanted to do in a year and summarize it, size it, and socialize it across product, engineering, design, and stakeholders.
I don't know what it is about me, but as soon as I realize that we have a process gap, I'm on it. So I built a template for annual planning and it did more than list projects. It walked people through how we work, what a POD is, how sprints run, what team capacity means, and the part nobody likes to hear, how a shiny new priority pushes planned items out of the sprint (delayed). It showed stakeholders how to be better partners at intake, so we caught problems early instead of paying for them in QA downstream. That document is what let a group of people who'd never done in-house product actually plan and ship together.
That annual planning template was used the next year. And we even moved planning up by several months so that the team could get a preview of what was coming and start the process even earlier. Having a template and a way of working is the kind of thing that enables those outcomes.
Standing up process? You need buy-in.
Setting up process at a newly formed startup with team members who dislike meetings, can't agree on process or ownership and never had a retro is another beast entirely.
Standing up an org meant defining the operating process and how we work. So, I wrote our team's playbook. We did one-pagers that defined the "what" (context, goals, requirements, held by product and design) and stories, written with design and engineering, broke down the "how" (implementation and acceptance criteria, held by engineering) in bite-size deliverable pieces. Against my better judgment, I set up an async standup in Slack with Geekbot and instituted weekly grooming to refine upcoming stories. I also set a clear story-writing standard and a release and production-testing guide that made "done" mean verified in staging, then production, not just merged, with clear statuses in our tracking tool so it could also be a reliable source of truth for every deployed feature.
The human part, working on how we work as a brand new team, was so important to me, and did not go over well ultimately. I set up a workshop series to build trust and psychological safety before scaling, including "Working With Me" manuals so people knew how to work with each other, a real org chart, clear decision boundaries, and 30/60/90 goals. From my POV, you can't stand up a team's process without standing up the team.
Failure of leadership to allow for psychological safety alienated team members and blocked iterative improvement. We didn't have a single retro in 6 months. What healthy organization can claim that? It was an organization that wasn't able to continuously improve because we had no mechanism for it. Feedback also became difficult because we didn't practice it openly. And since we didn't have daily live standups, issues languished longer than they needed to. We didn't do a daily parking lot, and so velocity slowed. We were going at a fraction of the pace we could go, all to save the team ~15 minutes a day and ~1 hour a week. The cost was months of development time, high frustration, and a team that never got aligned.
I pulled every process lever I could. I brought in an outside facilitator focused on scrum and team process, brought in the team, my boss and the CEO on process changes, iterated on existing processes, and pitched leadership on important changes. What I learned is that a team's way of working only sticks when leadership co-signs, and no amount of influence from the middle can overcome that. What I'd do differently isn't the work. It's how fast I'd realize whether the leadership actually wanted the changes, and how much of my energy I'd spend on process changes.
Standing up a team without buy-in from leadership is the hardest part of this entire job. If you don't have it, you can do everything else right and still be stuck.
"Move fast and break things"
"We don't need process, just ship. Stop talking about it and do it." I've heard this more than I care to admit. Every org that doesn't fundamentally understand the importance of clearly identifying what we're delivering and how we deliver it, and doesn't lock down how we work, who owns what, who's responsible for what, and how teams want to operate rather than how your last team worked, is missing the thing everything else depends on. I have watched organizations that ignore these fairly simple concepts completely run themselves into the ground. Moving fast without discipline is usually just doing rework multiple times with a lot of extra panic. Good process, clear ownership, and autonomy are how teams ship efficiently. And I know nobody wants to hear this, but great outcomes usually start with, gasp, slowing down to speed up.
It's a really cynical person who would say "process is what people reach for when they can't ship." I would challenge anyone to take a few minutes, even if they think it's silly, to set some ground rules for how we work together and then come back later and tell me they regretted having the clarity on how we work versus just barreling through, shipping and reworking time-consuming and costly mistakes. I'd argue that because time and money are so precious in startups, this is only more important, not less.
This is the hill I'll die on: process can't save a team that won't be in a (virtual or physical) room together. I've seen teams get so allergic to meetings that they gated access to customers, treated engineers as too precious to interrupt, and rarely demoed their work. You can build the cleanest async cadence in the world and it still won't fix it. Some things need a live conversation and a shared screen: watching customers and stakeholders demo and use the thing you built, seeing a customer's face when an experience confuses them, settling a disagreement in five minutes instead of letting the team argue in a stagnant Slack thread for a week. The goal should never be zero meetings. I'd rather aim for zero wasted meetings, and, crazy idea, just enjoying the meetings we have and showing up with the right energy.
Why I keep doing it
I think it's a compulsion, maybe? Setting up and refining product delivery processes don't usually get celebrated. But there's something about having a clean intake process, work cadence people trust, and a definition of "done" that really means done. It's electric when you get it right. To the right folks, those are some of the most rewarding things to see in an organization, because when you nail them, the team gets to spend its energy on solving real problems. You can feel it instantly when the process isn't there, the low-grade dread, the sense of chaos, the ennui of a place where nothing is repeatable and everything requires you to talk to so-and-so for this and so-and-so for that and none of it is written down or understood. Who wants to wade through that? I've been called a "wrangler" because I can walk into a mess and come out with a plan to turn it around. It's not the first thing you picture when you picture product management. But if your job is to ship good work efficiently and keep a team that wants to stay, good process matters to product folks.
Here are some questions I'll leave you with. Does your team clearly understand how your process works end to end and how an idea becomes a shipped product? And if you disappeared for a month, would they still know how to decide what to build and how to ship it? If those answers live only in your (or someone else's) head, it might be time to start thinking about your organization's product delivery processes.