Is this what we really need? We often build the tools faster than the problem can reveal it self to us. The reason why we call workflow issues ‘pain points’ is because that’s what they actually are: pain. A feeling, and that is hardly enough to work with. A company must therefore investigate the symptoms to arrive at the problem. When it’s isolated and defined, we can imagine how the outcome of the teamwork would be if this problem was eliminated. That takes care of the Why, and helps us answer the following three questions:
1. What tool should we build to eliminate that problem?
When the problem has been defined, the solutions we think of become easily assessable for their appropriateness. When a team knows what it wants the answers start to form almost by themselves. There are methods we use to get here faster: User experience design processes like persona studies, customer experience maps, prototypes and AB testing are tools we put to work regularly in these early stages of software design. Often, we do these together with stakeholders. Two things to keep in mind at this stage is to focus on outcomes, and not outputs (features), and to come up with testable hypothesis and not set-in-stone beliefs. This stage is all about questioning and finding a small set of possible solutions going forward.
2. When do we need to implement it?
Good software takes time — by setting clear and realistic timelines a software company can often reach a priority objective in a relatively short timeframe. That is, if the team (stakeholders and software studio) are absolutely clear as to what needs to be produced, are on the same page and commit to a series of sprints to achieve those objectives, time can be managed and goals achieved sooner than we sometimes expect. At Seb Azzo, we use a method called One-In-Ten: we reach an objective every ten days. The objective is a set of features (or one big feature) that is congruent with the next business milestone. This is important for momentum and quick, small wins which are essential for team morale.
3. How much resources can we afford to build this software?
A common misconception is that software must be paid in full upfront or on delivery. This is a bad way to go. Software should be broken down into small objectives, each prototyped quickly (in a day or two) to be validated by users. Prototyping activities are cheap but yield very high value: clear, actionable feedback. With this in mind, stakeholders aren’t required to lock down large amounts of resources for one single project, instead release small chunks as and when ideas are validated. This means that money is more likely to be spent on the right activities.
The important point to keep in mind is that the early days of software development should be about forming testable hypothesis. But routinely and affordably validating these hypothesis (ideas we think can work to solve a given problem) a company can have the essential questions answered before making great investments in long term development.