Your product is more than just features

We often reduce our product to the things they do, assuming that it’s the features that make people want to buy and use it. But this only forms part of the story, it’s not only WHAT a product does but HOW it does it that can make it saleable and profitable in the long term.

As a Quality Coach, my role is to help people understand how to ensure that what they’re working on (or building) is good. This means considering both the breadth and depth of what’s to be built in terms of quality and how good it is.

When we think about the depth of how good things can be, it can cover a lot of things:

• FUNCTION & FAULT TOLERENCE; does it work? Does it meet what we wanted from it? Are negative and edge cases of functionality in the feature catered for well? Is it good enough to meet people’s expectations in terms of behaviour?
• PERFORMANT; is it responsive when someone makes a request or do that have to wait? Will it break or crash when lots of users or data is being used?
• SECURE; will it leak data or can somebody access things they shouldn’t do? Is there trust in this product as being somewhere you can store sensitive information?
• USABLE & ACCESSIBLE; does it feel good to use, for everybody? Can people understand how to do the things they want and use the features to execute that well?
• SCALEABLE; if we roll out the product to more and more people, will this work? Can we maintain and support the product features and infrastructure as it gets sold more?
• SUPPORTABLE; can we identify and fix faults or make improvements to our product features? Will those changes we have to make be fast to do? Can we reduce or handle the number of questions we’ll get about the feature?
• CHARISMA; does the feature have the it factor? Will it wow and delight our customers, making it marketable and desirable. (Read more about Charisma testing here.)
• PROFITABILITY; will this make money? Will we get more revenue from sales than it costs to develop and maintain / support the feature? Can we sell enough of it?
• AESTHETIC; does it look good? Is it branded, sleek, modern and something that’s pleasing to the eye?

You’re likely thinking “Callum, these are just non-functional requirements” and you’re right. The depth of any given feature comes in the form of the non-functional aspects that tell us how the feature works in the real world. Unfortunately though, these key aspects of making our features frequently get lost or ignored which leads us to a very shallow product.

Why do we forget the depth?

There’s not a simple one size fits all reason for why we might not go as deep in thinking about our product beyond just the features we aim to implement.

Doing it waterfall

When I used to work in old banking projects (remember the V Model anyone?) we only used to check the non-functional elements at the end. It was its own phase, had its own dedicated testers and was generally kept apart from functionality and general requirements.

It could be that this mentality persists through to modern development practices, that we’ll add in these things in our last or later iteration. But this means that customers using our current product aren’t getting the best experience and raises the question, would we rebuild everything if it’s found to not be good later?

Features mean revenue

We make products to make money and when we think of what will sell we can focus too much on thinking that features sell. Rather than iterating to improve, teams move on to the next thing and the product gains more and more breadth as a way of chasing new sales or increasing prices.

But chasing breadth through customer facing work isn’t the only way to make more money. Improved user experience through usability or responsiveness could lead to more sales or stopping customers leaving. Higher supportability could mean faster patching of problems, leading to customer happiness and a reduction in support costs for the organisation. Having fault tolerance and more usable features can also lead to less confusion and less of a support burden too, saving money there.

Gotta go fast!

For some teams there’s a pressure to just deliver. That we have to make any cuts and compromises that we can to get features over the line and out to customers. This pressure might well be real, or might be assumed / imagined, but it’s a very real feeling that software delivery professionals do have.

If we make the wrong cuts to depth, like maintainability, supportability or code health, then we can really ruin our own velocity by not being able to make changes to the product in a timely manner. It can even lead to have to make massive refactors to the codebase, meaning we cannot deliver any new features or feature changes for quite some time.

Thinking it’s a testing concern

Depth of feature is just a fancy word for quality right? That means we can leave it to our quality professionals to deal with right?

I’ve seen situations where the depth of features is looked at in terms of testing only; for example instead of talking about security it’s always security testing / pen testing. This limits aspects aspects of our features to just benchmarking or a tick box exercise, something we do because we’ve been told to but with no plans to actually improve our features.

Not having an opinion

It’s easy to think about features and customer behaviour, depth and non-functional considerations are harder and more abstract to think about so sometimes we don’t. A number of organisations don’t add non-functional requirements to their definition of done or don’t have a documented view on these. That can be because we don’t know who should be the one to have an opinion, we don’t know how to form an opinion or because it’s too early to care about these things yet.

When I’m coaching teams, I usually let them know that we should have an opinion of what we’re aiming for in terms of depth from the start. I also make the recommendation that it should be the Product Owner that owns setting the view on how good things need to be (informed by experts). Without a target to hit in terms of feature depth we cannot plan, know how long it’ll take or make an informed decision on whether what we’re building is good.

Why does this matter?

All of this matters mostly because we want to make good products. Only thinking about the breadth of feature set is a common issue that can lead to many issues in a products lifecycle such as:

• It’s not good, so people don’t want to buy it.
• Teams getting bogged down in support so team velocity slows.
• Service failures in live that need managing, slowing team velocity.
• Law suits from customers (in areas around security and accessibility).
• Reduced profitability, from increased maintenance costs and less sales.
• Poor developer experience with managing code, making staff retention hard.
• An inability to maintain or change the code and features quickly.
• Not feeling good about our work, leading to disengagement and more issues.
• Having to refactor or rebuild everything as issues are found too late to do small fixes.

As product development specialists, whether you’re a quality specialist or not, we need to be considering and making informed decisions about how good things need to be right now. If we’re working on thin slices of depth to drive shorter time to market we need to consider what trade offs we’re making. We also need a plan for how we’re going to improve the depth of features.

To help teams where the depth of features is not being defined, we can use testing to help. That’s where exploring beyond just what’s been asked for is important, to tease out and show where a lack of depth can cause problems.

More Blogs

LinkedIn