Product Process at Kieffer Bros.

We’ve spent a lot of time talking about how we build things at Kieffer Bros. We’ve also spent a lot of time helping other teams improve their processes to make better products. I thought it would be worth sharing how we approach the complex endeavor of making a software product.

First, we like Agile philosophy. That is, shipping early and often. Learn as soon as you can. Be ready to pivot as you learn. Don’t get too bogged down in process and tools. And yes, some product concepts are hard to avoid a waterfall-esque approach, but keeping these basic ideas in mind can save you from wasting time. I really like this article by Umar Ali explaining the difference between the agile philosophy and the process frameworks that have arisen around it.

With that said, here’s our process framework. It’s loose and a somewhat gray on purpose. There are four main steps:

1. Product Strategy
2. Design Sprint
3. Building Sprint
4. Validation

1. Product Strategy

Primarily the Product Manager/Owner’s responsibility.

On this step we identify unknowns, document strategy decisions, and prioritize problems to solve. To make good decisions this step will often require information gathering. This can mean crystalizing business priorities. It also likely includes user and market research. This step is where we make sure we understand the problem we are solving.

The artifacts produced at this step are primarily documentation. There should be product summary documents, design briefs, research summaries, etc. Designers and engineers contribute with feedback and critique. Designers (and researchers, if you are lucky enough to have some) should be involved at this step in information gathering and critique.

2. Design Sprint

Primarily the Product Designer’s responsibility.

This step is all about agreeing on the best solution. It’s important that there is team buy-in here. The outputs of this step are design specifications / flows, technical design documents, and job stories / acceptance criteria. Product owners and engineers contribute with brainstorming, feedback, and critique. This step might also require engineers to do research and protoyping.

It’s worth noting that we use the term “sprint”, but we are playing fast and loose. A sprint might mean a true scrum sprint that lasts exactly one fortnight, or it could just mean the amount of time it takes to complete a shippable chunk of work. We’re also specifically not referring to the Google Ventures Design Sprint, which is a week long process where the entire team pauses on their typical responsibilities and everyone participates full time in design excercises.

3. Building Sprint

Primarily the Engineer’s responsibility.

This is where we write code. By now it should be very clear and specific about what needs to be built and what success looks like. Product owners and designers contribute by helping resolve questions and testing.

4. Validation

Shared team responsibility.

Did we solve the problems? What did we learn? Do we need to pivot our strategy? Does any learning adjust our priorities? This step is the key to staying agile. With a full cycle staying under a few weeks, the team never gets too far along planning for a non-viable future. Your strategy is always informed by your most recent learnings.

Overlapping Cycles

Another thing to note about our process is that it assumes a team of people with designated roles. Depending on a person’s role, they may have more or less responsibility within a step, but this frees them up to start working on the next cycle when their primary step is complete. This results in overlapping cycles, so there is always a continuous stream of work for the team.

Summary

In summary, we build products with a cyclical, agile approach. It’s a mashup of a lot of different frameworks and ideas. It’s loose and fluid, and it has worked well keeping us on track with side projects over the years.

Posted July 21, 2023