(i.e. the problems we're solving)
We've found that most teams who build software products face a set of interrelated problems:
- Building and shipping new features takes too long. The codebase gets out of hand as teams forget to remove old code. Code stays branched longer, merges are more complicated, and deployments are riskier.
- Understanding how the product is performing is too difficult. Much of the data collected from the product is incomplete or unreliable. It’s hard to tell which data is trustworthy, and it’s easy for tables and schemas to fall out of date. As a result, analysts and data scientists waste valuable time wrangling data.
- Optimizing features is too costly. It’s difficult to understand whether experiments are succeeding, either on their own or in aggregate. Training and deploying new machine learning models is expensive. And, data scientists are slowed down by difficulties in gathering training data and waiting for other teams to deploy their models.
Though these problems seem unrelated, they all stem from a single common cause: product features are not clearly defined. Any new feature—a cross-sell, a search algorithm, a checkout flow, or any other piece of a product with a user-facing element—has a definition. What the feature is, how it will be used, what pieces will be optimized over time, and what data needs to be gathered about the feature are all defined somewhere, even if only implicitly. Right now, that definition is scattered across the codebase, product documentation, and project management tickets and comments. This makes it very difficult for teams to understand and manage features throughout their lifecycle.
Product management, product marketing, analytics, data science, DevOps, and engineering all have a stake in building and optimizing features. But they don’t all have the visibility they need. As soon as the planning for a feature is done, reality starts to drift away from the documentation. Product documents aren’t kept up to date, JIRA tickets only capture a moment in time, and table schemas don’t keep up with the code. This makes it harder for team members to understand what these features are and how they function.
Because a feature’s definition is fragmented, companies have to use a patchwork of tools to manage features. Each tool can only see and manage a narrow slice of the feature. An event tracking system to implement tracking, an ETL to assemble the data, and a product analytics tool layered on top. Then a feature flag system to turn features off and on. Plus a separate experimentation tool, or a separate suite of tools for data science teams.
The result is a poor separation of concerns—analysts need engineers to verify tracking, product managers need engineers to handle basic copy tweaks, data scientists need engineers to deploy models, and so on. This friction makes it harder for every part of the team to manage features.
Taken together, limited visibility and poor separation of concerns slow down product teams. It’s harder to build features, it’s harder to optimize features, and it’s harder to measure their performance.