Common App Building Mistakes That May Be Costing You Money!

September 20, 2018

Episode

2

Click bait title or no, this is episode #2 of Getting Apps Done. Joshua Graham talks to us about some of the common mistakes he sees people making when they set out to build the next great app and explains the impact in time and money as well as what you SHOULD be doing to avoid them.

Tune-in using

00:01
Hey there, welcome to another episode of getting apps done. A -mostly- non-technical podcast about delivering applications.
00:09
This is our second episode. In our last episode, we discussed how to make apps that work. Today, I thought I'd talk about a few of the most common things I see that delay or derail, delivering applications and give some actionable advice to help you save some time and money.
00:27
My name is Joshua Graham. I'm a technical consultant and I help businesses build software, basically, and in this podcast I would like to talk about and probably sometimes go on about how to get apps done.
00:42
Now when you're building an application, it's really easy to get wrapped up in it and to get excited and to start building it straight away, but there are actually a few things that need to happen before you get into building your application that are really critical to making sure that you do build an app that works for the people you're building it for.
01:00
And in my last episode, I discussed what value you are providing to your customer, but I didn't talk about how you figure out what that value is and how you confirm that it is actually going to be valuable in the first place.
01:14
Which is the first thing that I see is people tend not to validate their ideas before they go build them. They get what they believe is a really great idea and they set out to build it straight away. Now the problem with that is, not necessarily their idea, but the fact that they haven't spoken to the people that they want to build software for. And validation really is all about connecting with your target audience and learning from them as early as possible, before you even start to build your software, to learn what it is you are building for them and whether or not they believe that's going to be useful to them.
01:52
And that's actually a really big thing. It's not just a software development thing. It's when you're building any product, you need to know who you're building it for and how it's going to help them. And if you don't know that, and in fact I've done this myself, I have built applications without speaking to the target audience, and when I got to the end I realised I didn't even know who my target audience was. So I was building something for somebody, but I didn't know exactly what that was. And it's impossible to build a good product that works really well if you don't know who you're building it for and what problem you're solving for them.
02:26
So start small, get out and find out who it is you think is going to use your software. If you're building a recipe application, you probably don't want to go talk to a bunch of builders unless they just happen to be builders who like to cook as well. You want to go find somebody who does a lot of cooking, maybe chefs. Maybe your application is specifically to work with restaurants and chefs staff to help them train new employees or maybe to keep track of custom recipes they've made for their store or whatever it may be. That's who your target audiences and that's who you to talk to.
02:59
And in that case, if you are building that application, you don't want to go out and talk to a bunch of people who are cooking at home because they have very different needs. They have a very different set of problems and the solutions aren't always going to work for both of them. So you need to identify who that is and go start to talk to them and that's actually, that's the best part of all this is working with the people that you want to build these apps for it because that's why you're doing it.
03:21
You have some appreciation for these people and, honestly, if you don't have any appreciation for them and you're just doing it for the money, you're doing it for the wrong reasons. You should be talking to these people and you should enjoy talking to them because, if this is going to be what you're doing, you're gonna be doing a lot of it and you really should enjoy talking to the people you're building stuff for.
03:38
Because, let me tell you, once you've built this application, these same people are going to be coming back to you asking for new features, they're gonna be having problems and you're going to have to talk to them all the time.
03:48
So if you don't enjoy talking to them, I think you should probably reconsider who your target audience is and what you're trying to do because these are people that you should want to be talking to and you're going to have to.
03:58
And validation is going to help you with that as well. Because before you even start to build the application, you're going to start to identify, do I like talking to these people? While you're asking them these questions and they're responding to you... or not responding to you. You're starting to see what it's gonna. Be like to work with these people on a regular basis and that's a really good thing to know upfront before you start to spend a lot of time or money building something for them.
04:21
And once you to do speak to them and you have come up with something that you believe is going to provide value to them and your validation has proven to you, by speaking to them, that they believe this as well. You then need to prove the concept.
04:36
By proving a concept.. we're actually talking about another part of validation, but it's kind of an enhancement on validation. You're going a step further. You're not just talking to them, but you're actually starting to implement small pieces of either functionality or concept that you can take to them and let them play with.
04:58
Now that could be that you're building some wireframes that they can click through or it may be that you are somehow otherwise mocking it.
05:04
I've heard of a case where a company wanted to see if people would order from a bar while sitting at their table using their phones and instead of going out and building an app, they actually just put a card on all the tables saying, "if you'd like a beer, please text this number." Just to see if people would pick up their phones and order the beer by doing something on their phone instead of walking up to the bar and the first place.
05:23
It didn't cost them any money. They didn't... or it cost them very little money, whatever it costs to print out the cards. And they didn't have to go develop anything before. Just getting an idea of whether people would actually be interested in this at all. It was proving that concept. It was taking it a step beyond actually just asking somebody at the bar, "would you like to use your phone?" But seeing if they would actually act on that because saying you want to do something and actually acting on it are two very different things.
05:51
I think we've all had those moments where we say we want to get out and be more active and it never happens. Or we say, I'm going to take more photos of this year and it doesn't happen, or I'm going to build apps that work this year and it doesn't happen. Whatever it may be. There's a big discrepancy between saying we want to do something or we would do something and actually doing it.
06:13
And the proof of concept is all about proving that they would take that action, not just that they say they would.
06:21
And one of the key things here is, because we haven't completely proven that they're going to do anything, we don't want to do too much. Because, we want to be able to quickly change and pivot or iterate on what we're building so we can move and adjust with what our evidence is showing us.
06:39
And when we're talking about early application development, I'm going to say there's a lot. Don't get too attached to anything because it could all be throwaway. You may not proceed with this or even if you do, you might take a completely different path and you really don't want to get attached and stuck on one idea this early on.
06:57
Once you do firm up what it is you want to build. Though the next big mistake I see a lot of people make is what I like to call the kitchen sink syndrome. And I completely understand why people do this because you want to build the best application you can and you want to try to cater for anything and everything that people might want, and actually that's a trap.
07:23
I have fallen into this myself quite a few times where I get stuck on trying to cater for what people want instead of taking a step back and figuring out what is the core of what they need.
07:34
And in software development, we call this the MVP and I know in sports that's the most valuable player, but in software that's the minimum viable product and that's exactly what it is. It's the minimum amount of effort we can do to build something that's actually viable and provide value to our customer.
07:55
Our goal is really to deliver a product that helps people in some way. It doesn't have to be perfect to do that. The reality is most of the time if somebody's got a problem, they're not gonna wait around for the perfect solution. They want something now that's gonna help them and the less you need to build to do that for them, the quicker you're going to get it done and that's good for them and it's good for you.
08:17
So the key is not to over engineer things. And, for example, this is non software related thing, but the concept is actually the same. I used to commute every day and it wasn't a long commute. It was only about six miles from my house, which isn't terribly far to go, but as a default I went out and I bought a car and I got insurance and everything else that comes with a car and spent a lot of money on this car to drive to and from work.
08:42
And it worked really well. It took me about half an hour. Our traffic isn't that great in town, but it did the job and it got me to and from work and it beat the pants off walking. Let me tell you. I don't mind walking in. I don't even mind walking six miles, but I don't know that I want to walk six miles there and six miles back every single day going to work, particularly in the summer or winter or when it's raining and all those things that just make it not that great and the car solved all those problems for me.
09:07
But one day I decided, you know what? It's a really beautiful day. I'm going to ride my bike to work and the thing I found was it took exactly the same amount of time to bike there. And it was a much nicer commute because I got to ride down the canal and there were ducks and trees and everything that I enjoy. I like being outside. And I'm sure it was better for the environment and I didn't have to deal with stoplights and people doing silly things on the road and it was much nicer to commute that way.
09:37
And I realized I hadn't built a minimum viable solution for myself. I had gone out and I'd spent a lot of money on a car that I didn't necessarily need.
09:47
Now to be honest, cycling isn't perfect, is not the best solution ever. In fact, there was an occasion that I slid on some ice and nearly put myself, my bike and my work clothes and my really expensive Macbook all into the canal, which wouldn't have been quite ideal. That wasn't what I was hoping for that day.
10:06
But in general, cycling actually tick the box for me and it was a lot cheaper and it was actually a better experience than driving into work every day. But what I had done was I had gone above and beyond and I had over engineered my solution.
10:18
Had I, from the start just got the bike, I would have saved a lot of money and I would've been much happier because the bike was so much better than walking and that really was all I needed. But because I overthought the solution and under thought what the minimum solution was, I had spent a lot of money that I really didn't need to spend to get myself to and from work.
10:41
And you can do the same with applications. You can overthink it. You can add too much in and miss building something that, actually, might be a better solution for them because you didn't think about what the minimum viable solution was or the minimum viable product.
10:58
This is all about making sure that you are not building things you don't need to build or that aren't going to be beneficial to your customer or aren't the right solution for your customer. Validating it and proving the concepts and building the minimum viable product helps you build a better solution in the first place.
11:16
And you begin to iterate within a particular cycle of validating new ideas, proving that they work and then building them in a minimal but functional way for not only your initial development but all of your future developments as well.
11:31
I will let you take all that in and I will put up some transcripts on gettingappsdone.com.
11:36
Be sure to also check out joshuagraham.info if you want to learn more about me and why you should pay attention to me at all.
11:42
Don't forget to subscribe and make sure you do check out our website and drop me a line.
11:47
Until next time, thanks for listening.