Product Development Process

Overview

Wunder’s product development process aims to be simple and biases heavily toward ownership by the folks closest to a project (i.e. “Driver Drives”). We cherry-pick pieces from existing approaches (namely Shape Up and Agile) and freely adapt methods to fit our needs.

Weekly Prioritization

We work on a weekly cycle wherein each person on the team directs their own prioritization. During the weekly planning meeting each engineer suggests a set of individual priorities for the week (feature work, bugs, etc.). These decisions are informed by the backlog and roadmap defined by the product team. The ultimate set of work committed to in a given week is discussed and adjusted as appropriate.

Prioritization and Shaping

Every quarter, product conducts a series of user interviews and leadership discusses general business priorities in order to ensure that the metrics we are focused on driving with our tech resources are still in alignment with the businesses needs.

Given these goal metrics (e.g. reduce time spent on Y process, improve quality of X output), the product team engages in problem discovery work to better understand the underlying pieces of that problem space and opportunities for tech involvement. This process results in a Problem Discovery (or “Tee-Up”) document that is handed off to the Product Manager who will be responsible for the resulting feature. This document identifies a specific piece of the general problem space they should focus on, gives a sense for the amount of time we are willing to spend on this problem, and points them in a rough solution direction. These documents can look a lot different and offer a varying amount of solution detail depending on complexity of the problem space. Here are examples of Tee-Up Docs for a smaller feature and a larger feature.

After a problem doc is handed off to a Product Manager, they enter the “Shaping” process. We generally try to make shaping a concentrated activity for the Product Manager. You may hear them say that they are in a “Shaping Week.” This means we have tried to clear their plate of all other responsibilities so they can be heads down on a problem space for the week. During that week, they should be talking to users and other stakeholders, getting feedback on designs and solution ideas from other product team members, and potentially seeking engineering advice on certain technical considerations. The outcome of the shaping process is a “Pitch Document”. A pitch should lay out the requirements and constraints of a proposed new feature. If you are involved in a new project, you will be invited to a project kickoff meeting where the pitch is presented to the engineering team as a mechanism for the engineering and product teams to align on open questions, scope, “rabbit holes”, and timeline expectations.

Technical Scoping

After project kickoff, we move to an explicit engineering design phase called Technical Scoping. Technical Scoping reserves space for the engineering lead of a project to solidify implementation plans and collect feedback on that plan. This process can take anywhere from hours to weeks depending on the project.

For most projects, we like to see some sort of output from Technical Scoping that codifies the decisions and trade-offs made. The output can come in many forms (whatever works for you!) but here are some common examples:

Ultimately, the process of Technical Scoping is fluid depending on the project and the engineering lead’s preferences. Regardless of form, Technical Scoping ensures we have the space to find simple and effective solutions to problems and continuously improve our code.