If you haven’t already, check out the first post in this series: It’s easier than you think, lets build a web app

Part one  – Frame the problem

This phase should focus entirely on identifying the problem/s that need to be solved without the influence of technology.

Let’s consider this in our example:

Note: the example below is of a  fictitious company, any resemblance to real businesses, living or dead, is purely coincidental.

Company: App-Makers

Category: App Development Startup based in Melbourne, Australia.

Problem: New customers are often referred to App-Makers by existing or previous customers (which is a great thing!). However, this can often mean that early interactions with a customer are recorded in Facebook chat, SMS messages, and emails with different members of the team.

Due to the disparate information, the company doesn’t currently have an easy way to identify:

• which customers are referring them on to others,
• why some customers are referring them more than others,
• which types of customers are contacting the company via a referral, and
• what the preferred method of contact is for new customers who approach the company.

Having access to this information would allow App-Makers to better understand which customer segments they appeal to the most. The company plans to use these details to focus their future customer development and marketing efforts. In addition, the company would like to be able to easily identify their referring customers, so that they can regularly reach out to them and show their appreciation.

You may already be thinking of some clever solutions that could solve these problems, but hold onto your hat, we still don’t have enough information. In fact, we’ve barely scratched the surface!

What we have here is a neat set of goals, but we don’t have any details or any context of why the company works the way it does. We also don’t know if there is any other information that might be creating or influencing the identified problems.

Can you think of 3 key questions that you would ask the App-Makers team in order to dig under the surface?

In this scenario, when we’ve described the problem we haven’t suggested that it’s impossible to gather the required information the company needs – just that it’s not currently easy. This is also something that we’ll need to drill into. ‘Easy’ is a relative term; so we’ll need to define what the term easy actually means for the App-Makers team, and understand any blockers in the way.

We can ask our questions and get a better understanding of the assumptions that App-Makers operates under, by understanding how the company works.

We’ll explore App-Makers’ business workflows further in the next post.

Business Processes and Workflows – Part 2

Analyse and Identify the Problem – Part 1