Design for failure

Recently I heard a story where a customer was asking a cost estimate for his new mobile app. The customer had specified 100 features that should be included in the app.

My friend replied to the customer that he can’t give even a ballpark estimate with this many features. Do you really need all these features for the first version of the app?

The customer comes back with features cut down to 50, but with a hurry — “I already got a cost estimate from your competitor”.

My friend thinks “An app with 50 features is a big project and big projects are hard to estimate. How the competitor managed to get an cost estimate this fast?.

This is not uncommon situation at all. I decided to write a story of what the customer might did before contacting my friend — as well as some tips to avoid common pitfalls in software projects.

The culture of defining things

Almost every software project starts with defining. Why are we doing this project? What are the goals? Who are responsible? What is the return of investment?

We need to define our project for requesting a proposal. The more detailed the project definition — the more accurate proposal. By an accurate proposal it’s easier to get an idea of return of investment.

We tend to think that with specific definition the job can be done right in the first place, specially with people we don’t know.

Getting into details

So, we are building a new mobile app. Why? Because the competitor already has one for every platform.

Naturally we are setting a goal where we should be better than our competitors. First requirement for the app is that it should be available on every platform.

Benchmarking the competitor

Why is the competitor so successful with their app? How did they got so much users? What would make our app better?

They have quite a lot of features in the app: login with Facebook, a nice way of sharing photos to social media services and other cool features.

We can do better, let’s give an option to use Twitter, LinkedIn and Google+ for login. What if we would provide a way to share videos, too?

Now we have specified features for login (Facebook, Twitter, LinkedIn, Google+) and social media sharing (photos, videos).

Eventually we got a list of 100 features or improvements for the app that would make it superior to competitor’s.

Return of investment

After time and effort is put to project definition, we need a cost estimate.

Which company could do the app at the lowest cost and as fast as possible? Shouldn’t the actual software development be pretty straightforward with the definition this clear?

We send out a request for proposal for companies that make apps. A few of them is getting back saying that for a fast release, some features need to be cut off.

Luckily one company promises all 100 features in three months. Clearly the last company provides the best return of investment, since they’ll make the app at the lowest cost, fast and with all the needed features.

This could something that the customer did before contacting my friend. The story doesn’t tell, but hopefully my friend directed the customer to a correct track. I think he also smelled that otherwise that project would fail big.

How to fail small

Most software projects will fail but the question is — will they fail big or small?

Before starting a new project — whether it’s an app, web site or an online shop, figure out answer to these questions.

  • What is the problem I’m trying to resolve?
  • What is the cause of this problem?
  • How this problem could be solved?
  • I’m I the right person to solve this problem?

In my story, what was the problem? Was it the need of an app because competitor had one, or was it to win competitor’s users? Or ultimately, was the problem that competitor’s was engaging users more effectively?

Is the app only way of winning competitor’s users? Were they doing the best they can on other services? Even if they could get the users, how could they tell if an app will engage them? Ask them.

“Would you use our app? — Why?”
“What features would you expect our app to have?”

The answers might be surprising and probably will differ what you might have imagined.

Now you have a better understanding that the app can be a good way to engage users. You also got a hunch of what the app should be — and what features you should focus on.

It’s quite safe bet that that more engaged users will eventually convert to business and — eventually increase your market share.

Before you really decide to make an investment for the app, ask yourself a few questions:

  • As an organization, are we ready to provide app(s)?
  • What does it require from us?
  • Are there any hidden costs?
  • When does this project end (if at all)?
  • What if our app fails?

It’s crucial to identify the real problems that are being resolved. By identifying real problems, it’s easier to verify that we are doing right things rather than doing things right.


Differentiate goals from your vision or mission. Set realistic goals — something that can be reached. If possible, set your goals moderate or maybe a bit below the realistic ones. At least be sure that you are not communicating your ultimate visions as a goals that should be reached instantly.

If you set goals that can’t be reached, you’re creating a circle of underperformance. This underperformance creates pressure for people not making their goals.

If goals can’t be reached, the whole project fails with stressed people trying to save it, or worse — destroy it.


Now that you know what your users want and expect — design your app based on these facts. Prioritize the most crucial features and brutally cut off the unnecessary ones. Aim for fast release — and in case of a mobile app, start with one platform.

Keep in mind that people are often trying to add features that helps them to reach their personal goals — regardless the impact for the app.

“Steve from marketing said that we need login option for Twitter. Could you add it?”

If somebody asks to add a new feature — think carefully if that feature is really needed. Does it solve some real problem? Does it add some value for the users? Does the users expect this feature? Listen to your users and make decisions based on facts.

- “95% of our users use Facebook, so we’ll go with that for the first version”


Almost every software project come with surprises that nobody were aware of, even the most simplest things. Often these surprises introduces a bunch more of a kind. Note that it takes time to solve these issues, and other features might depend on solving them.

Deadline comes hand in hand with prioritization. Cut off features over bending the deadline. There‘s plenty of time for new features and changes after the first release.

Fail, analyze and refine

Even if you have created an app with features that your users want — it still can fail. What if users don’t find the features or don’t know how to use them?

Try to design your product so that it’s measurable. Analyze how people use your product. Which features work and which doesn’t? Why?

It’s always easier to analyze and refine a product with a smaller set of features. Maybe a small navigation change would help users to find the feature they want?

Experiment the features (UI, layout, text..) to see what works the best — and what impact it might have on other features. Keep in mind that if you are doing A/B testing — it gives you an answer for which case is working better.

In all software projects it’s people who make it happen or not. Create an environment where uncertainty and failing is ok — and where all goals and failures are faced as a team. If you are using a contractor, remember that they are part of your team.

Learn from your mistakes and fail small.

In Finland, we are having a social welfare software renewal project estimated 335–430 000 000 €. Request for proposal was 2 000 pages. What are the odds of making this project fail small, on-time and in budget?