The pitfall of Feature focused development

Product development is a layered approach.

When developing software or any other service, you use a layered approach to determine which features to implement next.

The layered approach:

1. Who you are as a company; We are the {Topic) company
2. What you are to your customers and what not, We help customers solve {Topic}
3. How that relates to your product strategy and its roadmap; What (Product), where(customers/channels), and what not and where not = focus
4. Create a backlog of possible items to implement; Check if the items align with points 2 and 3.

Feature focussed

After creating your roadmap and prioritising your backlog, you can fill your sprints and start implementing the chosen features.

The goal is to create tickets that can be implemented in one sprint. This often means splitting larger items into smaller ones.

During ticket implementation, the development team focuses on making the features work as well as possible. When development is based on isolated feature development, this is where things can go wrong.

We know, or think we know, that this feature is what the customer wants; he wants to be able to {Topic}.

Workflow focussed

The often overlooked Topic is the workflow, or how the customer works.

The feature-focused User story will focus on what the customer wants to achieve.

• As an Admin, I want to be able to be alerted on {Topic}

The flow-based User story combines what he wants with when and how:

• As an Admin, my daily work involves {Topic}.
• I want AppX to support me in solving {Topic] by providing:
• A dashboard that provides notifications on the number of alerts
• When I click on the number of alerts, I see a list with the following field that helps me determine:
• What to do,
• The urgency and impact.
• I can then open an Alert and get detailed information to {Topic}: List of items

Workflow throughout the application

The above is an example of a workflow within a feature, but the same needs to be done between features. It's standard for Development teams to consider how features relate to each other.

How these features relate to the customer's workflow and goals is less frequently done. It's the user story that goes like this:

• 'as a customer, I want to achieve this, and these are the steps I need to take using feature 1/2/3/4, and this is the information I need in each step while using multiple features'.

Layered approach

Again, we should use a layered approach, describing our customers' goals, the workflows supporting them, and the features they use. Only then can we get an application that offers the proper workflow and features that align with how customers work.

In short, when developing a new feature, make sure you look at the grander scheme and, most importantly, close your eyes*😑 and think: How would my customer use this? He logs in, and then...❓

* 🤔or investigate by asking your customers for feedback.