At Blaze, we support hundreds of thousands of users across an extremely complex and broad product with a technical team of just 10 engineers, 1 designer, and no full time PMs.

So we've put a lot of thought and intention into every aspect of how we work together.

Why? The process you use to bring together design, engineering, and product to create and iterate on what you sell is make-or-break for every startup. Do it right and you'll build something people love fast enough to outcompete the big guys. Get it wrong and things will grind to a halt, talented people will leave, and you'll slowly die before you ever really inflect.

The world's most iconic companies are all known for having robust, unique product development cultures: Apple, Nike, Hermès. But they didn't wait until they were juggernauts to develop them. Those cultures were shaped by their founding teams from Day 1.

Deciding how to work together to ship great shit can be tough when you're starting from scratch - a classic blank slate problem.

Now that our small team has been working together for 5+ years and we’re closing in on $10M/year in revenue, I want to share with you Blaze's internal guide to "How we build product."

Feel free to use it as inspiration to create your own product development bible. Take the best, leave the rest, and no matter what, have fun building!

Pace: It's all about Speed to Feedback

We prioritize speed to feedback because we believe that product excellence is a function of iteration—and the only true way to improve is to see how customers use what we've built.

At some companies, moving fast might mean significantly cutting back on scope, or cutting corners on quality.

At Blaze, we move fast while maintaining quality and preserving the most important parts of the feature, in part, by hiring really great people and running great planning processes.

This looks like:

• During (or ideally before) a feature handoff, product, design, and engineers will work to sequence a new feature into milestones in the handoff process.

• The most important area of value of the feature should be prioritized first, rather than the first part in a user flow.

• Generally, we aim for milestones to take no longer than 2 weeks from start of coding to customer release post-QA.

• The exception to the speed rule is that we'll never ship a feature if we don't think it meets our quality bar for customers - if it's not simple, easy, fast, and fun, then we'll keep working on it.

Prioritization: Bugs first, features second

Our top priority is keeping the customers we have.

Building new stuff is exciting—especially for us internally, because we like new challenges—but customers don't pay us for a product they don't know we're building yet.

We also know that the idea of "build it and they will come" is not true: more features do not lead to more customers.

Customers are already coming to us for the product we've built, and it's our job to make sure it works well.

Practically, this means:

• We prioritize bugs ahead of new feature work.

• We assign bugs out everyday in standup.

• These bugs have SLAs that typically range from 24 hours (urgent) to 5 days (high) because we know that solving a customer issue fast is just as important as solving it at all; customers will not wait around for weeks, or even days, if they are blocked.

• We will readjust feature timelines and the roadmap based on the extra time required to fix customer bugs.

Core Roles

Everyone's important to building quality products

Engineers, designers, and product managers at Blaze have equally critical roles in building quality products.

Product is responsible for deciding what to build, in what order, and why. Product owns the prioritization and sequencing of the roadmap, including customer bugs.

Their core output is a product spec (PRD), which outlines a feature's business case, customer requirements, external benchmarks, and wireframed flows. This happens, to a lighter degree, in bug or enhancement tickets.

Design is responsible for determining how a feature will work, including core flows, entry/exit points into the broader application, frontend user experience, and error resolution. Their core output is a Figma file that is ready for development, including all states and edge cases.

Engineering is responsible for how to build a feature, and in what sequence. Beyond the core output of a workable feature that's ready for customers, they also produce an engineering spec (ESD) for a feature, which outlines the development approach, milestones, timing, unknowns, and any research to back up assumptions.

Unlike other companies, we rely on engineers to help develop and refine the plan for a feature, not just "close off tickets." The best engineers do their own benchmarking, provide feedback on designs, and ask questions about unclear or overloaded scope before committing to their plan. Engineers own the product just as much as PMs or designers do.

We think about the development process as a series of players "passing the ball," and we have three sets of "handoffs" where one team transfers key ownership to another:

• In a design handoff, Product briefs Design on a new feature; the handoff is complete when the designer gives an estimate to the PM and both agree on the plan.

• In an eng handoff, Design shares finalized designs with Engineering; the handoff is complete when the engineer gets an approved ESD from the PM.

• After a feature is code complete, everyone—PMs, engineers, and designers—QAs the feature. See more about QA below. The feature is ready for release when all parties agree the feature meets our quality bar for customers.

QA: Get OK with redoing work

We do QA differently at Blaze. QA is not an afterthought; it is our last defense against releasing bad work to customers that does not meet their expectations.

Therefore, we do not have a QA team at Blaze; everyone on the technical team is responsible for testing every feature we build for customers (bugs are tested by the assigned engineer, relevant PM, designer, and Head of Engineering).

"High quality" means:

• The feature works technically without errors or bugs 

• The feature meets the customer's job to be done: it does what customers need and expect it to do

  • This is different than a feature working technically; a feature could be perfect code-wise but still not satisfy the customers' job to be done

• The product is simple and easy to use

• The feature is fast

• The feature is beautiful and delightful

• The feature works well responsively on mobile 

Note that many of these quality bars do not have to do with just well written code. Indeed, QA can surface many issues, including:

1. Issues with the technical implementation

2. Issues with the design of the feature

3. Issues with the scope or direction of the feature

This means that during QA, we may find problems that are not the fault of the engineer at all, but were errors or bad assumptions made earlier in the development process. Even if this happens, we may decide to redo the work.

This can be frustrating to the engineer, because it may result in "yield loss" or wasted work. We will do everything we can to minimize these mistakes, which is why good planning with incremental milestones that prioritize the most important assumptions first is so critical.

Unfortunately, even when we're thoughtful about our scoping and design, sometimes the only way to see what's right is to feel how it actually works in the product. And in the cases where we're wrong, we will keep working on a feature until we feel it's ready for customers.

Documentation: Write everything down

We have a culture of async collaboration at Blaze. This is partly because we're a fully distributed team: we work across 4 different time zones spanning 8 hours, so it's impossible to meet all the time as a way to get stuff done. Also, meetings suck.

But we like documentation because most people are better writers than talkers, and better readers than listeners, and so writing enables us to be more thoughtful and structured in our planning.

Our primary sources for truth are PRDs (written by PMs) and ESDs (written by engineers), along with Figma design files (owned by design). Docs are sent out for approval during handoffs, and we use comments and "approvals" to align.

If we're working through a complex topic where async comments are inefficient and unwieldy, we'll often call a sync Zoom meeting to work through it together.

Overall, assume that if it's not written down in your ESD or as a comment in a PRD or the design files, we do not see it. We use Slack for non-urgent/non-important chats, but it's not a source of truth for us. Do not use Slack for important questions or topics.

Expectations: Deadlines are a Negotiation

Between bugs, quality changes, and our desire to move fast, there are multiple competing priorities for an engineer's time at Blaze—so you may ask, how do I balance it all? 

We do believe in deadlines at Blaze because they create an artificial incentive to move fast. If you set an aggressive deadline, you will do more than you would if you set a lax timeline.

However, deadlines are a stake in the sand; they can and will move as things change.

Our expectation of engineers is not to hit their original deadlines, but to communicate with us as things change. As unforeseen work, customers bugs, or QA issues arise, we expect engineers to proactively update their ESD and communicate new timelines.

You will never be "punished" for adjusting your timeline. We may reprioritize or resequence the work to get stuff out to customers faster (see "Speed to Feedback"), but that is on the PM to figure out, not the engineer.

Collaboration

Winning is a team sport, so ask for help!

The #1 way we see engineers burning out is by trying to "be a hero:" attempting to figure out problems on their own even when they don't have the information or context to do so successfully. At Blaze, success is getting quality product out to customers - NOT by doing it all on your own.

Our best engineers do not start their work until they have what they need to do great work. They ask for more details from PMs, highlight gaps in designs, or perform quick technical spikes before they start. They are not afraid to ask for more, because they know that they can't "look good" unless they have everything they need to succeed.

So, our advice and request of you is to ask for help, especially if you're new. We're here to support and unblock you. Winning is a team sport.