Foundations vs. Features

We recently landed on a rough framing for thinking about how we approach building things in Arrows. If this resonates, or you have experience walking this line between foundations and features in early stage startups I’d love to talk to you—benedict@arrows.to.

It’s helpful to distinguish between Foundations and Features so that we don’t build a feature when we need a foundation, and don’t build a foundation when we need a feature.

Features are what solve a specific users problem. Foundations are the system that features are added to.

An integration system is a foundation, a Salesforce integration is a feature.

There’s always an implicit foundation when building something. The question is whether it’s a strong foundation, or a weak foundation. The stronger the foundation, the less work it is to add a specific feature.

When building something one of the biggest questions is always: do we need a new foundation, or to improve an existing foundation, before adding a new feature?

Feature Building

Success Modes:

• Quick shipping
• Product momentum
• Wins new customers
• Makes existing customers happy
• Solves the core problem without overcomplicating it into a generalized solution that isn’t needed

Failure Modes:

• Treating a foundation like a bunch of features, leaving us with disparate features that would be better unified underneath a foundation
• Coalescing several features into a foundation requires removing functionality in a way that makes us uncertain how it will affect current users, adding friction
• e.g. “Okay we want to redo emails…how painful will it actually be for existing users to adapt to that new email system?”
• Unabstracted code imposes a long term cost that makes it harder for other team members to use and contribute to the code
• Team members don’t feel like they get input or understanding of how the feature works and see obvious improvements that can’t be included
• Desire for speed leads to lack of collaboration between teammates making people feel isolated, and like they aren’t improving their craft
• Features are more likely to require followup work that needs to have time be properly allocated

Foundation Building

Success Modes:

• Lays groundwork for the product roadmap that enables rapid shipping in the future over the next 2 years
• An abstraction and code that is clear to understand and can be worked on by anyone on the team

Failure Modes:

• Treating a foundation like a feature, leaving us with something that isn’t strong enough to build on top of confidently
• Chasing foundation capabilities of businesses whose entire business is built on that capability
• e.g. automations in our product chasing full marketing automation tools
• e.g. task features in our product chasing project management software
• Building a foundation that we don’t build features on top of in the future
• Trying to squeeze too much functionality within a foundation that would better be served by splitting up the work into a couple foundations, or a foundation and some features
• Presenting ourselves with a long timescale when we box something as a foundation means we lose a sense of swiftness
• Losing product momentum
• Don’t win new customers as quickly
• Existing customers feel stagnation