.png)
When you bring a development agency into a product build, some of the first useful questions they'll ask aren't about features. They're about who the product is for, what it should feel like, and what makes it different from tools that already exist. The answers shape everything downstream: what gets scoped into v1, what gets deferred, what the onboarding flow sounds like, whether the design system leans minimal or expressive.
Founders who've thought through these questions get better proposals, fewer surprises mid-build, and a product that holds together from launch. This guide covers the brand decisions that have direct product implications, and the vocabulary you'll want before that first conversation.
Product scope depends on brand decisions more directly than most founders expect going in.
Who you're building for determines the complexity of the experience. A consumer-facing event discovery app and a B2B event management platform can share significant feature overlap, but they're built differently — different onboarding depth, different auth patterns, different assumption about what users arrive knowing. An agency can't scope one without knowing which product they're actually building.
Positioning determines what belongs in v1. When Bizzabo committed to the enterprise B2B event market, that positioning made certain features non-negotiable at launch — SSO, CRM integrations, GDPR-compliant data handling, custom reporting. Those were the minimum required to be taken seriously by enterprise buyers. Ticket Tailor made the opposite call: simple, affordable ticketing for independent venues meant deliberately excluding those same features. Same broad category, entirely different v1 scope — driven by brand positioning, not by technical preference.
Voice affects every text-bearing surface in the product. An agency building an onboarding flow, writing error messages, or designing empty states needs to know whether the tone is warm and encouraging or efficient and direct. Those choices accumulate across hundreds of small decisions throughout the build. Without a clear direction, each developer and designer defaults to their own judgment, and the product ends up feeling like it was made by several different companies.
Visual direction informs the design system. A product built for corporate event planners at enterprise companies signals credibility differently than one built for independent promoters running club nights. The design system — component choices, spacing, typography, how dense the UI is — gets established early and is expensive to redo. An agency making those calls without explicit direction is making brand decisions on your behalf.
A few specific brand decisions tend to produce the most downstream product consequences. These are worth working through before an agency conversation, because they'll come up whether or not you're ready for them.
Who specifically you're building for. Generic audience definitions produce generic scoping. "Event organizers" could describe a festival promoter, a corporate event manager, a conference producer, or a community organizer running monthly meetups — each implying different feature depth, different integration requirements, and a different quality bar for the UX.
Splash built their product for corporate marketing teams running branded experiences for mid-to-large companies. That decision drove specific choices: Salesforce and HubSpot integrations as table stakes, white-label customization, detailed guest management, lead capture tied to CRM fields. Those features would have been scope creep in a product built for a different audience. For Splash's audience, they were the baseline.
The more precisely you can define the target user — their context, the alternatives they're currently using, the specific thing they find broken about those alternatives — the more accurate the scope estimate will be, and the fewer mid-build conversations you'll have about what's actually in.
What the product will and won't do. The clearest input a founder can give an agency is a constraint: one category of customer, one use case, or one type of request the product explicitly doesn't serve. This is more useful than a feature list, because it lets the agency make scope decisions independently without coming back for clarification on every edge case.
Tito built developer-friendly event ticketing with a deliberate focus on simplicity and API access. The product has no built-in email marketing, no advanced promotional tools, no attendee networking features. Those aren't gaps — they're decisions. Tito's users integrate their own email tools, their own CRMs, their own whatever-else via the API. The product is focused because the constraint is deliberate, and that focus makes scoping straightforward: if a feature doesn't serve that model, it's out.
The products your users already use. Referencing two or three existing products your target users interact with daily is one of the most efficient ways to communicate design and experience direction. Not as products to copy, but as signals — "our users use Notion and Linear, and the product should feel consistent with that world" tells an agency a lot about expected information density, interaction patterns, and visual sophistication. It also tells them what to avoid: "it should feel nothing like Eventbrite's organizer dashboard" is equally useful signal.
These terms come up in agency conversations. You don't need to be an expert in any of them — you just need to know what an agency is actually asking when they use them.
ICP (Ideal Customer Profile). The specific type of customer you're building for, defined precisely enough to make product decisions against. An ICP is useful when it's specific enough to exclude someone: "corporate event managers at 500+ person companies running more than 20 events per year" is one; "event organizers" isn't. When an agency asks about your ICP, they're asking for the definition specific enough to scope against.
Positioning. What makes your product the right choice for that specific customer, given what else they could use. In an agency conversation, positioning matters because it determines which features are table stakes (required to be taken seriously by your target user) and which are differentiators (the things that make them choose you over the default). A product without clear positioning produces a feature list with no clear hierarchy — everything feels equally important, which makes prioritization conversations harder.
Brand voice. The consistent personality that comes through in everything the product writes — onboarding copy, button labels, error messages, notification text, emails. Agencies making UX writing decisions without voice guidance will make them based on their own judgment or on convention. If the product is meant to feel like a knowledgeable peer rather than a corporate tool, that's worth communicating explicitly, because it will affect hundreds of small decisions across the build.
Visual identity. The set of signals — color, typography, density, illustration style — that the product sends before anyone reads a word. In a product brief, visual identity direction usually comes through in references: products that feel right, products that feel wrong, and the reasoning behind each. "It should feel like Fever, not like Cvent" communicates a lot in five words if the agency knows both products. If they don't, unpacking why those references feel different is itself a useful conversation.
Differentiation. The specific reason a user would switch from what they're currently using. This matters in a product brief because it determines what the product has to do really well — not just adequately. An agency building a product where differentiation is speed will make different architecture decisions than one where differentiation is flexibility or depth of customization. Vague differentiation ("better UX," "simpler") doesn't give the agency enough to make those calls.
Four things, written down beforehand, will make an initial agency conversation substantially more useful.
A one-paragraph description of the target user. Not a job title — a person with a specific situation. What they're currently using, what's broken about it for them, and what would make them willing to try something new. This is the single most useful input for scoping decisions.
A positioning sentence. One sentence that captures who you're building for, what problem you're solving, how you're solving it, and why someone would choose it over the alternatives. It doesn't have to be polished — it just has to be specific enough to make decisions against. If you've worked through a product hypothesis using the Foundation Sprint format, you've already written this.
Reference products. Two or three products your target users use daily that the product should feel consistent with, and one it should feel nothing like. The reasoning matters more than the names — "consistent with Linear because our users expect a certain level of craft and responsiveness" tells an agency more than the reference alone.
The v1 constraint. One sentence on what the product won't do in v1. The more specific, the more useful: "we're not building multi-currency support in v1 because our initial market is UK-based independent venues" lets the agency make a dozen downstream decisions without asking. A general "we want to keep it simple" doesn't.
Agencies working with founders who've done this thinking tend to produce better first proposals — more accurate scope estimates, fewer assumptions that get revisited mid-build, and a design direction that reflects the actual product rather than the agency's defaults.
The conversations also go differently. Brand direction that's been thought through ahead of time gets discussed and refined rather than invented from scratch during a scoping call. That's a better use of everyone's time, and it tends to produce a brief that both sides actually agree on before the build starts.
None of this requires a completed brand strategy. It requires knowing, specifically, who you're building for and what you want them to feel when they use it.
Think of us as your tech guide, providing support and solutions that evolve with your product.
.png)
