It was never a design process

“So I just need to know where to put it in the UI.”

That was our CTO, Rob. Engineering had been experimenting with plan checks, a way to vet project plans so developers get better specs, and it was promising. I hoped this was an easy one. I thought, “Oh, just put a button somewhere and I’ll figure it out.” Let the record show: it was not an easy one.

Every role, same steps

Before I explain why, a little context on me. As a design leader at large product orgs, I’ve always been in the room debating product strategy, digging into customer pain points, and envisioning a better user experience.

Now I’m a cofounder and CPO at Grove, and the only product lead on a team of five: our CEO, our CTO, two engineers, and me. So I do more of everything. I drive the product strategy and vision, I plan and design each feature in detail, I contribute to content and marketing, and, thanks to AI coding tools, I submit PRs. My role, my responsibilities, and how I work with my team have all changed. What hasn’t changed is how I start.

Across my career, I’ve helped shape new products from the ground up, with teams of product, engineering, and business experts by my side. We’d find a problem worth exploring, then dig in. Who’s experiencing this pain? What do we know about them? What’s the impact? Do we need to solve this to compete in the market?

We’d bring people with all kinds of skills into the same room, usually a jam-packed workshop, to iterate through concepts, sketch ideas, rough out the shape, and weigh tradeoffs. We were all designers then, working to turn a subpar experience into a much better one.

Big problem or small, the work always comes down to the same steps: understand, imagine, test, learn, decide. A designer might say, yes, that’s the design process! A product lead might say, yes, that’s the product process!

An engineer or a scientist would recognize it too. They’re all right, because it was never a design process or a product process. It’s one way of working, and it doesn’t belong to any role or discipline. Rob’s team was already proving it: plan checks started as an engineering experiment, tested and promising, before anyone asked where the button should go.

Which brings me back to the button.

The button that needed a home

To figure out where a “check plan” button belonged, I first had to answer what it was checking. Plan checks vet a plan, but we didn’t really have one in Grove. We had a project requirements doc. The real problem wasn’t the button. Grove had no place for a plan to live.

So I took a step back to see what else that gap was breaking, and it turned out to be a lot. For most teams, a project has two distinct deliverables: a plan (what needs to be coded and how, usually called a spec or PRD) and a delivery (the code created according to the plan). Each has its own work to get it from start to finish, and usually a different owner.

We build Grove with Grove, so we felt this firsthand. When we walked through our work list to review progress and priorities, we had no way to know the current state of either deliverable: whether a project was building without a plan, who was responsible for what, or how to route questions about the plan or the delivery to the right person. Every work item needed a verbal explanation.

In a world where our tools can tell us exactly what’s happening on any given piece of work, manually updating a status field or asking your team “wait, where are you on speccing this out?” felt painful and archaic. I don’t want to bug anyone about status. I want to debate priorities and figure out when we have time to ship dark mode to that customer who asked.

“Where do I put the button” turned into a much bigger question. Plans and deliveries each needed to be real objects in our system, with their own states and owners, so Grove could check both and teams could see what on earth was happening without bugging each other.

My proposal was simple but risky: introduce Plan and Delivery as new concepts, rework the user experience, and redefine how status and state work across the entire product. This was a foundational decision, and a lot of future features would hang off of it. It was a big bet.

My team wasn’t immediately on board. More objects? More statuses? More fields? They worried. We worry constantly about every concept we introduce, because each one adds complexity, not just to the architecture, but to how people understand the product. Conceptually, the solution met our current and future needs. The risk was in the user experience. So instead of arguing for it, I built a prototype, and we tested it.

I knew it was the right call when, in one of the first tests, a participant asked the exact question our old setup couldn’t answer:

The prototype and the tests are what won my team over. They got to see it and experience it, not just hear me describe it. That did more than any pitch could have. I could also show that the new model unlocked more automation right from where the work actually happens: coding sessions and Grove planning sessions.

And the button? It finally had somewhere to go.

What actually changed

For me, the product work is the same. The weight is different. As a design lead, I made the case and someone else made the call. Now the call is mine, and so is being wrong. A foundational bet like Plan and Delivery is exactly the kind of decision you’d rather not get wrong, and I won’t pretend that isn’t a little scary.

What makes it manageable is that I try to make decisions out loud. My team challenges me, frequently bringing up ideas I hadn’t thought of. Prototyping and testing early means I find out I’m wrong while it’s still cheap.

Writing decisions down along the way changes the whole conversation. It’s so much easier to debate a decision with your team when it’s written on a page: they have something real to respond to, and my whole thinking is there, not a fragment I remembered to mention in a meeting. That’s a big part of what Grove does for me. It coaches me through the plan and keeps the reasoning in one place instead of in my head.

Even so, I don’t have time to do everything myself. I love conceptualizing and strategizing with my team, but the more I take on, the less time I spend in execution. I have to trust my team to carry more of it, and I worry about UX polish falling through the cracks.

Our branding project keeps sliding down the pipeline. Smooth motion animation? Currently a pipe dream. Someday I’d love to hire a killer design engineer to own that craft. In the meantime, I’m finding ways for the whole team to contribute designs, but that’s another story.

Anyone can shape what gets built

Underneath it all, it’s still the same way of working: understand, imagine, test, learn, decide, together. I’m just the one accountable for where it lands now. So I’m still designing; I just spend more of my time designing what we build, not only how it works.

And you don’t need a product title to do that. Engineers, designers, marketers, anyone close to the customer can help define what gets built. Don’t wait for permission. If you have a great feature idea, build a proposal.