Choosing a design partner after Series B

Three product teams are redesigning permissions. Each has a reasonable solution. Together, they are creating three different explanations of who can do what.

In this illustrative startup, the new funding has made hiring possible, but more design capacity will not settle the disagreement. Someone still needs to decide which behavior belongs to the whole product and which belongs to a particular team.

That is a useful starting point when choosing a design agency after Series B. First identify whether work is waiting for a designer, a decision, or an agreement between teams. The answer changes the kind of partner you need and the assignment you should give them.

Where is the work getting stuck?

Look at a few recent features that took longer than expected. Trace the delay through the actual handoffs. Perhaps a designer was unavailable. Perhaps the brief kept changing. Perhaps engineering discovered that two teams meant different things by “administrator.”

These problems need different responses. Embedded design capacity can help a team with a clear backlog and accessible decision makers. A shared product problem may need a focused cross-team effort. Repeatedly reopening the same strategic choice may require an internal leadership decision before an outside team can make progress.

Keep the diagnosis concrete: “Billing and workspace settings disagree on account ownership” is a workable brief. “Make us look like a Series B company” leaves the agency guessing what improvement matters.

The funding stage tells a partner something about the company’s context. It does not establish that the interface needs a complete redesign or that a new design system should come first.

Which decisions will the partner own?

Lenny’s interview, How Notion builds product, describes product work that crosses team boundaries: an enterprise-focused lead advocates for customer needs involving several parts of the organization. The useful lesson for an agency engagement is that a customer problem may extend beyond the team assigned to deliver one feature.

Before onboarding the partner, make those boundaries explicit. An agency can propose a permissions model and help teams evaluate it. The company still needs someone authorized to resolve disagreement about that model.

For the illustrative permissions project, use a working agreement like this:

The role names are placeholders to replace with real people. If nobody has time to resolve the first row, the project has an ownership gap. Adding another designer will not close it.

How should the engagement fit the existing team?

Ask the agency how its designers join the work already happening. Who attends product planning? Who speaks with engineers before review? How does a question reach someone who can answer it? When does the internal design lead see a decision that could affect other teams?

Require access to the people doing the work, not only an account manager. Explain which internal meetings are useful and which would simply consume time. The aim is a working connection, not a second organization of status calls.

Protect the internal team’s ability to disagree. An outside partner may spot a genuine inconsistency, while an internal designer may know why it exists. Ask for the evidence behind both views. Preserve a deliberate exception when it serves a real need; remove one when it is only an accident of history.

Humbleteam’s work includes product design and embedded design support. The startup agency guide provides broader options to consider. For this decision, ask every candidate how they would operate inside your team’s constraints.

What makes a first assignment useful?

Choose a problem that touches the relevant boundaries without committing to a product-wide overhaul. The permissions example could cover inviting a colleague and changing that colleague’s role in two existing product areas.

Define what the assignment should leave behind: agreed terms, an interaction proposal, a record of unresolved constraints, and a handoff the internal team can use. Agree on the commercial scope and acceptance conditions before work starts. Do not turn an agency selection exercise into an unpaid implementation project.

During the review, introduce a realistic conflict. One team needs a restriction that the other does not. Does the partner investigate the difference, force both teams into one pattern, or allow another unexplained exception? A good answer may include a shared rule with a documented boundary.

Include an engineer who did not attend the design sessions in the handoff review. Ask them to explain the proposed behavior. Their questions expose context that still lives in the agency’s conversations rather than in the deliverable.

How will you know the partnership is helping?

Compare the first assignment with the bottleneck you named at the start. Did the teams reach an actionable decision? Can engineering proceed? Does the internal owner understand the tradeoffs and know when to revisit them?

Track reopened decisions, blocked handoffs, and avoidable rework alongside delivery volume. More screens are useful only when the team can implement the right behavior. Keep any measurements tied to the particular assignment; one successful engagement does not prove that every team should use the same model.

Before expanding, confirm who maintains the shared work and how new teams learn its rules. The partner should leave enough context for the next person to continue. That is a practical test of scaling design: the fourth team can make its permissions decision without starting the same argument again.