‘Feature’ is a construct
Why features would make product development easier, but don’t exist 2024-01-16 #product
- Feature lifecycle
- Feature release
- Feature rollout
- Feature trackers
- Feature analytics
- Feature as construct ←
Features don’t exist. Product managers focus on the business outcomes, and developers focus on well-tested code changes. Everyone mentions features from time to time, but never precisely.
We imagine product features, but can’t say whether a product has ten or 100. Instead, we construct them on the fly, for the length of a conversation. They don’t really exist.
Documented features
Software user guides don’t document features. Technical writers use task-based documentation to explain how you can do what you want to do, using whatever features the software provides.
In practice, the following don’t match each other:
- what people want to do
- what the documentation explains how to do
- what the software can actually do.
If features did exist, though, you could map them to user needs, user tasks, and task documentation. Then you could ask, which features don’t have any documentation?
Released features
Software releases don’t add features: they incrementally update the whole product. These updates vary in complexity, updating different parts of the product in parallel, without regard to anyone’s idea of feature boundaries.
If features did exist, we might find it easier to write release notes, because we’d already know which features the release updated. But features don’t exist, only bug fixes and performance improvements.
Exclusive features
Features don’t exist for everyone, because we hide them behind feature toggles. The toggle seems to define the feature you can hide, but only temporarily. When we commit to the hidden functionally, and remove these feature toggles, their contents melt into the surrounding functionality.
If features did exist, we’d know which SaaS customers had which toggles enabled, and which features no longer have a toggle. In practice, product managers drown in feature toggle chaos that obfuscates feature boundaries.
Broken features
Customers occasionally report that something doesn’t work. Precisely identifying which ‘something’ broke would help resolve the issue, but you can’t just select from a list of all features. Because features don’t exist.
If they did, you could list currently-broken features, and prioritise corrective maintenance based on the importance of the tasks they support. In practice, you might as well use a zero bug policy to know what the list contains by knowing that it contains nothing.
Unreliable features
Features don’t exist, so a single recurring bug makes the whole product unreliable. But frequent bug reports often turn out to have functionality in common, like how leaks in an old house tend to return in the same places.
If features did exist, we might know about the unreliable ones that cause the most support requests. This might help us choose between replacing the whole roof, or only the gutter.
Unused features
Features don’t exist, so even if you know that people use your product, you don’t know which parts they use. Meanwhile, the software accumulates millions of log messages per day, but doesn’t have millions of features.
If features existed, software analytics would identify their activation, adoption, an abandonment. Product managers could ask about the last 30 days’ most popular features, and the ones nobody used.
Abstract construct
Features don’t exist. But we can’t make sense of complex software products based on their more concrete technical artefacts. Instead, we have no choice but to construct the abstractions we call features. Unfortunately, we do so half-heartedly.
