There’s a very tidy version of product development where Product figures out what to build and hands it to Design, Design figures out the experience and hands it to Systems, Systems writes the requirements and hands them to Engineering, Engineering builds it and hands it to Test, and Program holds all their hands along the way making sure everyone hits their dates.
I’ve never seen the best teams actually work that way.
The best ones are much messier, in a good way. The boundaries between the roles exist, but they’re a lot more permeable than a RACI suggests. I’ve worked with systems engineers who are incredibly product-minded, engineers who are great systems thinkers, and UX designers who uncover things that eventually become product requirements. None of that means the roles don’t matter. Obviously they do. But building a complicated product requires a bunch of people who are really good at different things looking at the same problem from different angles.
I think of it a little like an orchestra. Everyone has something they’re particularly good at, and you definitely want them to be good at it. But they also need to understand what everyone else is doing, know what you’re all trying to make together, and recognize when their part needs to lead and when it doesn’t.
The customer, after all, experiences one product. They don’t experience your org chart.
Everyone is working at a different pace
Robotics makes this really obvious because hardware and software just work on completely different timelines.
Software can usually afford to leave more things open. You can build something, try it, learn something, change it, and ship another version. Hardware would also love to do that, except at some point somebody has to release a drawing, order a part, cut a tool, work with a supplier, build the thing, ship it somewhere, and physically attach it to all the other things.
So of course hardware teams want decisions earlier. And of course software teams don’t want every detail locked down a year before they’re going to build it. Neither one is wrong.
I don’t think the answer is to declare that the whole program is Agile or Waterfall and make everybody plan the same way. I think you need to agree on where the whole system needs to be at different points, and then let each team work backward based on what it actually takes them to get there.
Maybe the first milestone is mostly about proving the riskiest pieces of the technology or the experience. The next might be the first time the whole system really works together. Eventually you need to know whether the actual product works in an actual environment with actual people well enough that you’re comfortable launching it.
Product, Program, Systems, Design, and the technical leads should all have a hand in figuring out what those milestones mean. Product is thinking about the customer and what we actually need the product to accomplish. Systems is thinking about how the whole technical system has to work together. Program is thinking about all the dependencies, timing, resources, and whether this plan can actually happen. Design is thinking about the experience a person is going to have across all of it.
Then everybody can work backward from the same points without having the same plan. Mechanical Engineering might need to commit to something months before Software does. Design might need to understand the whole experience now but only need really detailed designs for the first thing Engineering is going to build. Product can have a pretty strong opinion about where the product should be in two years without pretending to know every requirement we’ll need to get there.
Alignment doesn’t mean everyone is working on the same thing at the same time. It means everyone understands where the work needs to come back together.
Product and Design don’t just take turns
UX is probably the easiest example of why I don’t really buy the relay-race version of product development.
Early on, Product and Design might be figuring out the vision together. We’re talking to people, mapping journeys, figuring out what they’re actually trying to accomplish, where things suck today, and what a much better experience might look like. Design is part of creating the understanding that I’m eventually going to use to make product decisions and write requirements.
Then I might go deeper on strategy while Design starts exploring what the overall experience could actually look like. What are the major touchpoints? How do they fit together? Where does a person need to interact with the product? Are there completely different ways we could solve this?
That gives me something more concrete to react to, which usually makes my requirements better. Then those requirements give Design something more concrete to work from. When something gets closer to actually being built, Design can go way deeper on that part while leaving the stuff farther out more conceptual.
Sometimes Design is upstream of Product. Sometimes Product is upstream of Design. Sometimes we’re working on the same problem together, and sometimes we’re off working on different things in parallel. A lot of the time we’re leapfrogging each other: one person gets far enough to give the other something useful to react to, and then the work moves forward again.
That’s not unclear ownership. That’s just working together.
Plan the future without pretending you know it
This is pretty much how I think about roadmaps and requirements, too.
I want a strong opinion about where we’re going. I want enough of a plan between here and there that people can make smart decisions today. And I want a lot of detail about the next thing we actually need to build.
I absolutely do not need the same amount of detail for something we’re building next month and something we think we’ll need two years from now. Farther out, I care a lot more about outcomes, capabilities, and direction. As something gets closer, I want actual requirements, designs, interfaces, acceptance criteria, and a plan for how we’re going to know whether it works.
That gives hardware enough information to make the decisions hardware has to make early without forcing Software and UX to pretend we already know a bunch of things that we’re obviously going to learn later.
It also means Engineering might be extremely focused on something we need to prove in the next few weeks while Product and Design are working on something much farther out. That is completely fine. If the team already knows what it needs to do for the next milestone, I don’t think the Product Manager needs to go rearrange the backlog just to prove they’re product-managing.
Stay close. Understand what’s happening. Help if you’re useful. But you can also use that time to figure out what comes next, so when the team finishes proving the thing they don’t turn around and go, “Cool. Now what?”
And obviously you’re going to learn things along the way that change the plan. That’s not a failure of planning. That is the planning model.
A milestone should enable a decision
This is also why I care a lot about what a milestone is actually for.
Before an alpha, beta, integrated test, site acceptance test, limited launch, or whatever else you call it, I want to know what we’re trying to learn. What are we trying to prove? What evidence do we need? How much data is enough? Who do we need to test with? What would make us decide we’re not ready to move on?
Then you go do the thing and come back with what you learned.
The point of an exit review isn’t to convince leadership that everything is green. It’s to put the evidence, what we learned, what we still don’t know, and the remaining risks in front of the people making the decision so they can actually make a good one.
Maybe we should proceed. Maybe we need more data. Maybe we found a gap and need to go build something. Maybe something technically works but is way harder to use than we thought it would be. Maybe we need to stop and rethink part of the product. Or maybe we know there’s a problem, understand the risk, and decide we’re comfortable moving ahead and fixing it quickly afterward.
Finding out that something doesn’t work can be a very successful test. You asked an important question and got the answer before making a much more expensive mistake.
The milestone isn’t successful because you reached the date on the roadmap. It’s successful if you learned enough to make the decision it existed to enable.
Come back together regularly
Teams can spend most of their time working at different levels of detail, on different timelines, solving completely different problems. But every so often, you have to put the pieces together and see what you actually have.
This is where the orchestra comparison comes back for me. Everyone can practice their own part, but at some point you have to rehearse together.
A good demo does the same thing. Does this thing actually work with that thing? Did two teams make completely logical and reasonable decisions that turn out to be terrible when you put them next to each other? Is the experience we’ve been describing actually showing up in the product? What did we learn that changes what everyone goes off and works on next?
Early demos don’t need to look anything like the finished product, just like the first rehearsal doesn’t need to sound like opening night. Sometimes the most useful thing you can do is bring everyone together early enough to find the places that don’t work. Later, the demos get more complete, the system gets more integrated, and eventually you’re putting the actual product in front of the audience that matters: a real customer.
You can’t RACI your way into a good team
You can define who owns Product, Systems, Program, UX, Mechanical, Firmware, Software, Test, and everything else. Clear ownership is useful. But none of the rest of this works particularly well if everyone is guarding their part.
Mikell wrote recently about the importance of being willing to “talk it through, as a crew”. That’s a huge part of this too. The teams where this works have enough trust to actually talk about the messy parts instead of everybody retreating into their own functions.
Systems can challenge a product requirement without Product hearing, “Engineering doesn’t want to build it.” Design can tell me they think the product strategy is wrong. An engineer can have a much better idea than I do about the user experience. Program can say, “Guys, this plan is not real.” And Product can recognize that a team already knows exactly what it needs to do and just clear the path.
You need people who are really good at their own jobs but are also interested in what everybody else is trying to accomplish. You need enough trust that people can cross those boundaries without getting territorial, and enough respect for each other’s expertise that crossing a boundary doesn’t mean taking over.
That balance is weirdly hard to recreate. Sometimes you find it, the project ends or people move around, and then you realize just how much of what was working came from that particular group of people being willing to trust each other and jump in where they were useful.
But when it works, it feels really good. Everybody can go off in their own area without losing track of the whole thing. People can be working at completely different levels of detail and on completely different timelines, and somehow the pieces keep coming back together.
You spend less time arguing about whose box something belongs in and more time actually making the product work.
P.S. I did actually play in symphonic and marching band in high school, so there ya go.
About the author
