I’ve noticed that as of late, more and more of my posts seem to be about projects failing. This post is in the same vein, but will talk more about the “human factors” that you might want to consider before your product is launched – or before you even start working on it.
Let’s say that you’ve developed an app. It’s a pretty good app, if you do say so yourself. Your clients love it, too; they’re getting a lot of use out of it, and they’re very happy… at first. But little bugs and errors are starting to crop up, and the users are becoming a little bit frustrated. So you go over your code with a fine-toothed comb, trying to scrape up the bit of code that’s causing all these niggling little issues…
And then you realise that it’s not you or your app that’s at fault.
It’s all on the users.
They haven’t been updating their profiles, or synchronising their databases, or any number of other possible goofs and slip-ups. Which leaves you with a problem: how do you explain to your clients that their labour-saving program does, indeed, need some effort on their end? How much upkeep do they need to perform?
Have you considered what problems your product might have when your users haven’t been keeping their data up to date?
If you’re in the tech industry, usually you’re ultimately in the business of solving people’s problems. I think everyone in the tech industry should take whatever chance they get to hear about people’s problems. Well, within reasonable limits; you’re unlikely to come up to with a killer app to help your grandma’s gammy leg. Although you should be talking to your grandma anyway… but I digress.
If you start being receptive to it, you’ll hear phrases like this all the time:
“I wish there was a way to do <blank>.”
“I was trying to do <blank> but it was so hard.”
“I started to do <blank> but then I couldn’t figure out <blank> and <blank> I didn’t have <blank>. What a pain in the <blank>!”
You get the picture.
Any of these could be signs that someone has a problem that needs solving, and if you can build something great for them? They could be your next customer. The question is, would they use your product… and if so, would they use it the way it’s meant to be used?
Either way, keep in mind that whether it comes from your mind or the prospective client’s, every project starts with… an Idea.
Case Study: The Idea
It was a conversation like this with an acquaintance who we’ll call Sally that led me to The Idea. Sally had to manage her children’s school soccer team and was having problems organising it all. She kept running into issues like:
- Missing/outdated contact information for all the parents
- Trouble finding a practice venue central to everyone
- Difficulty organising carpools
- Time-consuming process of contacting all the other parents
Of course, there are existing products that solve some of these problems. Shared contact lists and messaging systems are nothing new. Where I thought there were some interesting problems to be solved were in the geographical areas. I’m going to call this app Kids Sports Practice Coordinator or KSPC for short. A catchy name that just rolls off the tongue.
Locating a venue
Obviously there are already ways to find things close to you. When you jump on Google Maps and search for “Pizza”, it brings up your neighbourhood pizza joint instead of one from the next city over. So it’s not like you have to start from scratch.
All our app would need to do is compute the centre point between everyone’s house then use that as the starting point for the “sports field” search. We could even get really fancy and have the app calculate the centre point based on driving time instead of distance.
After identifying a list of potential venues, what would happen then? In an ideal world, the venues might be hooked up to KSPC to allow booking and payment with a few clicks. More realistically, a group administrator would probably need to phone each one to check if they were available at a time that suited everyone on the team.
However, once you find a venue, how often do you have to change it? In theory, this app would be of most use if the soccer team had no choice but to juggle times, dates and locations every single week. In practice, once you’ve got a shortlist, well, human nature would probably lead to the group selecting one regular venue, irrespective of whether it’s the perfect option for everyone.
If one of the participants were to move house, then technically there might be a better option closer to the new centre. But it’s not like that happens more than once or twice a year (if at all), and at that point, isn’t it easier to stick with the venues you’ve already chosen?
And of course, the app’s functionality is predicated on people keeping their personal details updated. If they move house and don’t update the address recorded in the app, then not only is the app failing to help, but it’s actively giving bad data to the rest of the group.
In other words, it’s an interesting problem, but a dedicated app wouldn’t necessarily be the optimum solution.
Similarly, the carpool problem sounds interesting. KSPC could let parents enter the number of available car seats they have and then group riders together by proximity. We could build a rotating roster into the app, and even code in the ability to plan the route and let you know the most efficient order and directions to pick everyone up.
Except… what happens at 6AM on Saturday morning when your ride doesn’t turn up because the car is in the shop, and they didn’t update their ride status in KSPC?
Or, even worse: your ride does come to pick you up after practice but they didn’t change their seat availability to account for the fact they had to pick up their other kid from ballet practice before hand. Oops, now you’re stranded at soccer practice – maybe forever.
The human factor
The reality is, these things happen. People let things slip, get distracted, and forget to update their statuses and details. The only way to be sure that something is going to happen is to call or text manually to confirm.
So where does that leave KSPC? As you can probably guess, it’s not an idea I’m going to actually develop. I’ve talked about project failures and MVPs before. Sure, we can solve some problems with MVPs, but first you’ve got to actually make the user’s lives easier.
In my opinion something like KSPC is only useful if it’s absolutely bulletproof. This means making it feature-complete; reminders for people to keep their information up-to-date, a system that confirms that everyone has seen/accepted your messages, constant reminders to check in and confirm plans, and so on.
If it’s going to be reliable, it needs to be thoroughly automated and/or intrusive, which tends to put people off using the thing. Plus, it sounds like all that work of checking in and keeping things up to date is not actually saving users any time.
There’s no way around it though; as soon as you’ve let the users down once, you’ve lost their trust, and good luck getting them to come back.
If you think you want to take this idea and run with it, be my guest. I’m sure I’m not the first one to think about this particular problem and how it might be solved.
The process of use casing is pretty simple when you cut all the five-dollar words down to size. Basically, it consists of a few simple steps:
- Define the problem that needs solving
- Figure out what your product would need to do to solve the problem
- Try to imagine how the end users might use the product, correctly and incorrectly
- Figure out what your product would need to do to prevent those problems
- Rinse and repeat
At frequent points, ask yourself: would I want to use this product, given all of these needs and restrictions? If the answer is no, then either you need to rethink your approach, redefine the problem, or just drop the whole thing as a bad idea — hopefully, before you’ve gotten too deep into the problem.
This process can — and often does — result in saving a huge amount of time and effort, and has become part of almost every development process in the software industry.
Keep in mind that technology marches forward. The world keeps getting more and more integrated as the Internet of Things spreads. We already outsource a lot of our personal data storage to make it easier to update — after all, who hasn’t pressed the “Log In with Facebook” button at least once? For that matter, cars are getting smarter; soon enough, cars that log how many seats are filled may be common on the roads.
In a few years, the KSPC might just be feasible for use by soccer moms across the globe without being too aggressive or obtrusive. For today, our use case tells us that it’s an Idea whose time has not yet come.
The real solution
So, you might be interested in knowing how this particular team-coordination problem was actually solved.
With a good old-fashioned shared Google spreadsheet, of course.
Spreadsheets are ubiquitous, can hold any kind of semi-ordered data, and pretty much everyone knows how to use them. Over the years there’s been many attempts to displace them across different domains, but to quickly set up a document with arbitrary information, they can’t be beat (just yet).
For someone whose business involves writing bespoke software, I spend quite a lot of time writing about how to avoid writing bespoke software.
I still believe it’s important to know when software should or shouldn’t be developed, and when an MVP will or will not be sufficient to win over users.
When making these kinds of decisions, remember the human factor. You’ll need to consider how much work there is to do to make sure users engage, keep their data up to date, and allow your system to become bulletproof.