Rising Collectively, building brand and product in parallel

Rising Collectively needed brand identity, UX strategy for two very different user groups, healers and seekers, and a market-ready MVP, all at once, without the usual sequence of “identity first, then product.” This piece goes into how that parallel build actually worked, sprint by sprint.

Why sequencing wasn't an option here. A more conventional path would have finished the brand and visual identity first, handed it down as a finished system, then built the product against it. That path is safer, and it was also too slow for what this brief needed. The startup needed something market-ready fast, and treating brand as a completed upstream phase would have meant the product team sitting idle waiting on decisions that, realistically, needed to be tested against the actual product to be made well in the first place.

The structure that replaced it. Two-week sprints, with brand identity decisions embedded into the same sprint cadence as product decisions, rather than the brand being finalized and handed down separately. Positioning and the dual-audience user journeys, one for healers offering their services, one for seekers looking for them, were mapped early, and every sprint touched both the visual system and the working product simultaneously, not alternating between them.

What that actually looked like week to week. A sprint might carry a product goal (the seeker-side booking flow, say) alongside an identity goal (the color and type system that flow would actually use), decided together rather than one waiting on the other. When a positioning decision shifted, say, leaning the brand voice warmer and less clinical to suit the healer side of the marketplace, that shift showed up in the product's copy and UI within the same sprint, not three sprints later once someone remembered to update it.

Why that's a genuinely harder way to work, done deliberately. Running brand and product in true parallel only works when both are being shaped by people who can hold the whole picture in their heads at once, since a change to positioning language can ripple into a UI decision in the same week, and vice versa. It asks for constant, live coordination rather than a clean handoff at a fixed point. On a larger, more siloed team, that same approach would need much heavier process overhead to avoid one side quietly drifting out of sync with the other.

What actually shipped. A scalable MVP in React and Vaadin, ready for users and investors, with an identity that runs through the actual product rather than stopping at the marketing site. The two were never separated because they were never built separately, which is also why the brand feels native to the product rather than applied on top of it.

What we'd do differently. We'd sequence identity sign-off slightly ahead of UI work specifically on a larger team. The two-week cadence made it tempting to let both move at full speed simultaneously here, and it worked because the team was small enough to keep the whole picture in view, but it asked a lot of coordination to keep everything in sync, coordination that gets harder to sustain as more people are added to either side.