Developing IT products is an exciting task. Technology is complex. And product design is about to understand your customers and anticipate their needs exactly.
Along the KISS Principle we want to develop only features, we or our clients really need. Why do we need to focus on KISS?
The customer wants an easy to use product.
Manuals are bad: Your Product must explain itself without the need for any documentation for basic usage.
Development should focus on demands instead of selling. But getting the quote is important, too.
You can’t develop unless you know your user: Programming is formalized knowledge. You need a very detailed understanding of your customers tasks and needs to develop customer centric software. All software you write in advance will miss these needs, because you start selling your features instead of listening to your customers demands.
“The customer needs a feature”: This quote reveals you are doing feature driven development.
Feature driven development is based on an internal (marketing/selling) perspective. Instead of developing features that fit customer needs, feature driven development concentrates on features which can be presented (marketing / sales perspective) and may raise needs.
Most companies have to balance between customer- and feature-driven development. On the one hand they need displays to get quotes. But afterwards it needs real customer satisfaction to bind and keep the relationship.
Feature-driven features look great but (by definition) won’t provide real assistance to the day by day work of the customer. They are teasers to get the quote. No more. From a healthy development perspective they should be treated as what they are: A marketing campaign.
A little help to differenciate between feature and customer driven features.
If a feature…
It is a featured-driven feature and should be treated as marketing feature
If a feature…
It is a customer-driven feature which stronly contributes to the customers success stories.
So let’s define what the customer needs are…
Keep it short. Keep it simple. Don’t repeat yourself! Every word you write more is one more to read!
Images say thousands more than words!
infracamp.org<stakeholder> I want to <archive a goal> therefore I need <a feature>
Whenever you are dealing with commercial stakeholders, the Punchline should be some variation of
As business owner i want to <<specification of 'increase productivity'>> by <<some action>> therefor i need <<something>
where as you better define increase productivity by an actual faced problem and put the most reliable solution at the end.
As business owner i want to encounter rising fuel costs by replacing the most fuel inefficent (by savings) machines
by new ones. But I can't replace all of them at once. Therefor I want to start with the most possible savings.
As business owner i have different machines with different fuel consumptions that are used at variaing
frequencies.
I could replace the old, very inefficient ones - but they are rarely used eighter.
Or should I replace instead better replace a almost new one frequently used one.
Examples: Give at most 4-5 examples
Describe other possibilities to archive this goal. Name the consequences.
Describe what you as stakeholder would expect to meet your needs.
What has to be done before starting this task.
Feature driven development will work well for consumers by providing kind of lifestyle. And when it comes to business, feature driven development is highly effective for getting new quotes.
But business value will only apply on customer centric development approach.
Should we do mock-ups instead of wasting time in feature-driven developments?
Is the US a Minimal Viable Product (less features possible)?
Are the subtasks between 0.5 - 3 days of work?
Is the US independent from other development activities?
ml