Design the team before designing the product

I spent some years doing design and strategy in corporate venture studio contexts, helped found and run very lean start ups, and am currently a product design leader in a large, global B2C company.

When a project grows ambitious, people reach for a bigger plan, a bigger stack, a bigger team. The structure that moves best is usually the opposite: a small group that can decide, test, and change its mind. That is true in a venture studio, in a startup, and inside a large company that is trying to move more quickly.

Confusing the problem, new AI tools make tiny teams look cheaper and more capable... But, they only help if the team was designed to decide and learn. Otherwise, you have the same overhead, now with heavier prototypes. Here are some of my notes from seeing this play out over the years.

Small, strong teams

How can small teams maximize their impact when creating new products? What does a venture innovation team look like? What does a highly effective startup design team look like?

When a project grows ambitious, the pressing problem becomes less about building a product and more about growing a strong team. Strong teams are small, fast, and adaptable, but what does that look like in practice?

A key advantage of a small team is in reduced communication complexity: if the whole team can catch up in a stand-up that lasts only a few minutes, then it can spend more time thinking and moving. For a team to be fast, it has to be autonomous and make its own decisions: external stakeholders should be willing and able to hand daily oversight to an internal owner. And, there should be a hypothesis of the north star, it should be rigorously tested, and it should be adapted as more of the problem is solved. The scope of a north star could be company- or product- or even feature- wide; it doesn’t matter how big the field is, only that the bounds of that field are agreed upon.

A productive team should be able to meaningfully fill a few roles: plan and track tasks, research and analyze, plan executions, build executions, manage out to stakeholders, and maintain alignment to a larger strategy. All of these roles can be combined in one person (though, at great risk to maneuverability and burnout), and they can also be shared across individuals. However the work gets placed, every team member should be clear about and agreeable with how roles are divided up. As the team moves forward, the end goal will become more clear, and the weight can shift towards building; but be aware that an innovation and ideation team is not the same shape as a production and support team.

A note about autonomy

Creativity is highest when a designer can work without judgement. A team that can make messy choices and bravely dive into rabbit holes is more likely to connect dots that lead to market-shifting breakthroughs. Outside stakeholders can be a danger to this, especially when they feel strong stewardship over an idea or particular solution. If these stakeholders wield their oversight powers and approval gates to persistently steer a group towards their preferred path, all they've discovered is an expensive way to use up an innovation team's gas. A light touch approach will go further faster - and potentially dig up more useful insights that inform the overall strategy and solution. If a team falls on a flat solution: adjust the strategy, refine the north star, and start over.

Experts and generalists

Having a small team often means balancing expertise and generality in a way that prioritizes generalists long-term, and calls in experts for brief advising or research phases. In especially nebulous work, a naive generalist is in a better headspace to touch on novel and creative solutions, and an expert can advise on various angles that have worked previously. Combining both an expert and a generalist effectively often means deferring to the generalist while consulting with the expert - don’t expect an expert to do everything before they burn out. Having expertise live as a cross-team consultant opens up the possibility for engaging with outside experts as a research task or fractional participant, keeping the overall org nimble and adaptable.

A generalist is a great benefit in this kind of team structure: someone who is able to do a phase of research and then move to a phase of building testable prototypes is much more useful than someone who can only talk about strategy alignment. Related, plan for having flatter teams, knowing that flatness is always relative and ideal. Hierarchy within a team locks down roles in a way that eats away at innovation and adaptability.

Start and end with research

With the team in place, the most effective way to move forward through ambiguity is to treat every problem as a research problem: look at what you have, spin up a hypothesis, and test it. Start and end with research. Look into the problem beyond stealing solutions from competitors: question assumptions about root causes, draft out maps of how ecosystems behave, toss ideas down early and often, and put those ideas in front of people.

It’s easy to keep things internal, but important to bring in outsiders to keep from going stale. Bring in experts to talk about parts of the map that you don’t understand. Bring in customers to talk about what they do and try to understand their behaviors.

Strawman, sacrificial prototypes - test early, test often

At every stage, you should be open to being wrong, and you should make fearless new conclusions. At the end of every investigation, test the conclusions with strawman-sacrificial prototypes, running them in front of whatever audience is most appropriate for what you hope to learn.

Answering questions at the right altitude

One particular quirk of all this: you should match the fidelity of the execution to the fidelity of the idea. When testing loose ideas, a polished-looking execution will inevitably look or feel wrong. (How many times have external stakeholders looked at early drafts and gotten stuck on a meaningless detail?) A sketch is a sketch. Testing at the right fidelity gives you the feedback you need.

Some prototypes will be very small and tight, focused on an interaction or a layout; others might be large and rough, showing wireframe navigation across a whole service. Having a team that understands how to communicate and critique effectively is critical at this stage. A prototype serves as a visual or interactive response to a specific hypothesis or question, and being able to stick with that conversation at the right level is a skill.