Free Download: the 15-Point Checklist you Need Before Developing Your App
Creating a development team for a new application is an expensive step, and you want to make sure they start building a product idea with a good chance of success.
I meet so many people in a huge rush to start development and quickly abandon some critical steps of product discovery that would ensure success. Furthermore, they publish an app full of bugs, poor UX, and functionality. The killer blow is that the most expensive thing in product development is fixing the product once it's live.
That's why I created the checklist for app development. It's a 15-point comprehensive checklist to review before writing code for your new app or product. It covers user testing, business model, team members and development risks.
Imagine you skip the 15-point checklist and release a new app with critical bugs. Once live, you've already disappointed users; you need to go into maintenance, stop future development and fix existing code—painful stuff.
I also made a video that explains how to use the checklist. Here's a transcript of the video:
Hi everyone. I'm Mike from Apollo Advisors, and today we are doing a 15-point checklist. We're gonna go real quick. This is gonna be a checklist for you to use before you start the development of your product or your service. This will help you make development faster and more efficient, but more importantly, it's gonna help you build a product that's actually worth building.
Number one, has your idea been changing over time? If your original idea hasn't changed, developed and iterated over weeks or months or years, then really that's a proxy for me saying that you're not learning anything and any good idea should change and grow over time. So your. The question before you write code is, did you change your product idea at least two times?
And did you do that on the basis of learning and discovering what your customers wanted? Okay, that's number one. Number two, have you actually gone out and, heaven forbid, talk to real customers? Step one in that would be to do some quick surveys and use tools like type. Survey Monkey, have you actually surveyed at least 50 of your customers to verify that your product is actually doing the job to be done that it addresses?
Is that is that really reflective of the pains that they experience and the gains that they're looking for? So have you actually talked? Have you actually surveyed 50 customers to confirm that you're actually solving a problem that they want to have? All right, moving right along. The next one here is, did you do one-on-one interviews with at least 10 of your customers?
This is a bit different to the surveys that I just mentioned. In these interviews, you should be really looking to understand their behaviours and their motivations, and you're really trying to understand how your solution fits into them. If you haven't done ten user interviews prior to coding, you're wasting your time with your development.
All right. Now that you're building a really good image of what your customers need, you should prototype it. You can use paper pens; you name it, stickies. You can use it on a whiteboard. You can even prototype with tools like Envision Adobe xd. But these are ways of not having to write code and testing your idea.
You can actually create something that really feels. Your final product or service, your final app, but have you actually gone and prototyped this with your customers because you would be able to see if are they able to get the task done? Are you actually solving the problem? If you haven't done any prototyping with users before writing code, you are gonna waste a ton of your code.
Next one. You set out on a big mission. This is your company, whether it's a startup or an enterprise. But the real question here is, does what you do with this product, does it really serve the vision of the company? And a vision should always be about. Looking forward to a future state of how you're gonna have an impact on the world and your customers.
You have to really be able to ask yourself, how does this new product or service that we're building serve that? And you should be debating this, and you should be validating this because sometimes you can be a little off track. You can be very far away from your original. So I really suggest that before you write your code, check in on that vision statement and say, are we serving that vision statement?
Is this the best step forward? All right. Here's the next one. Number six. Do you have a clear argument for which horizon your product matches? Sometimes? And this is particularly in the enterprise, your product is like a defensive strategy. That's horizon one. Maybe it's a bit of an expansion, a bit of a growth strategy.
That's horizon two. Where a lot of startups tend to play is horizon three transformations. This is not just creating a new product, but creating a whole new business model. Which one of those are, you prove it and if you're thinking I'm not sure. Go to apollo advisor.com, and check out our academy.
We have a whole course on product discovery that will show you how to actually get into this horizon planning. Number seven, can you argue for industry and consumer trends that your product takes advantage of? Now, here's the really cool thing. You will probably find that there are different trends happening in the business.
By now, pay later. That's been a huge trend.
Microfinancing, that's an example.
Now, on the technology side, if you were to look at finance, definitely like blockchain or contactless payments, those are good examples, but the truly greatest startups and the greatest products, don't just leverage one of those.
They tend to have this trifecta between a consumer trend, a tech trend, and a business. So the big question is what trends are you taking advantage of and can you make a clear, valid, cohesive argument for which trends your product is taking advantage of? Nps, oh my gosh, this is such an important checklist.
Have you examined existing data such as NPS in reviews that are relevant to this use case? For example, if you're an existing enterprise, are you looking at your NPS data as a signal to where you should go? or if you don't have any existing product, go and create an NPS survey of people using the best-case solution as of today.
So if you're re-reinventing the automotive sector, get people's NPS from their current driving experience. This is really powerful data to inform your product. Okay, so you've got this clear idea about what you want to do. the outcome of how you might want to solve a problem. But there are different ways of solving a problem.
And what I would always encourage you to do as a checklist for product discovery is have you truly examined two different ways of solving the same problem? So you might do that in the user interface. You might do that at an application level or even at a data level, regardless of which one of those, it is really important that you do.
Sort of an AB test of two different ways of solving the same problem. Cuz you'll be surprised. There are so many ways to create a product and so many different approaches. You should at least have had two that you have compared to make sure the one that you went with is the best. Okay, number 10, we're getting through it.
Did you make a lean canvas? If you dunno about Lean Canvas, head over to apollo advisor.com. We have templates there for you in the product discovery course. But really this is a key thing. You don't have to write a full business plan, but you least need this lean canvas to summarize your approach. And in particular, there are two here on screen that I'd really point out.
Number one. Have you really got a robust, unfair advantage and a unique value proposition? These are really what is going to determine your success above and beyond anything else your capacity to do things differently and uniquely. So make sure you have your lean canvas. Okay, so you're building a team.
It's exciting. You're getting all sorts of creative people, business people, and tech people. The thing is, beyond all of those skills are behaviours. Creating a new product is full of unknowns and requires a really tight working team. So here are my ultimate three things you need when you're recruiting people.
They need to be collaborative and really great communicators. Two, they need to be adaptable. And three, if I was going for anything they are of a growth mindset. They love to continuously learn and improve. So don't just get people who've got skills. Get them with good behaviours too.
Number 12. Did you draft a lean hypothesis? This should come off the back of your lean canvas. This is a testable, precise statement you can break down. If you want to know more about how to do that, head over to apollo advisor.com. Check out the product discovery course. We have a whole bunch of thinking on the lean hypothesis, so do you have one?
Okay. Do you have a clear time-based roadmap for your MVP? Sometimes MVP development can go on and on, and. . You have to be careful about that. Never shipping. It's a huge problem. Make sure your roadmap is really tight and literally make it as lean and as minimum as possible. All right, write down all your learnings so far.
So before you actually build, make sure you write them all down. Think about all the different slight pivots change. Tweaks that you did and why you did them. Imagine that you're writing that for someone who's gonna join the company later. It's a really good exercise to be clear on what you've learned, and as I've said, learning is crucial when you're building a new product.
Okay. Lastly, together with your team, have you actually mapped, outlined and highlighted or flagged the risks that you have in development? For example, development is full of unknowns on technical dependencies, and access to resources. I've got a whole list here. Legal, security, all of these sorts of things that are gonna come up during development.
Have you actually identified them? You're gonna have. You wanna speak to other people who've built SI similar products, but it is crucial because then you don't have those terrible Uhuh moments where you didn't see something coming and it really damages your effort to get live. So make sure you've identified those key challenges you face in development.
All right, that's a really quick tour through our 15 points. I hope you are that much closer to building a killer app, and I want to thank you for joining me on this journey of learning. I hope that you've really got into this idea of product discovery. It's one of the most powerful things you can do to shift from guessing what customers want.
You don't have to guess anymore.
You can actually know what they want, and that helps you in design development, not only to get live but thereafter to grow your product too. So if you want to know more, head over to Apollo advisor dot. We'll see you later.I also made a video that explains how to use the checklist. Here's a transcript of the video:
Hi everyone. I'm Mike from Apollo Advisors, and today we are doing a 15-point checklist. We're gonna go real quick. This is gonna be a checklist for you to use before you start the development of your product or your service. This will help you make development faster and more efficient, but more importantly, it's gonna help you build a product that's actually worth building.
Number one, has your idea been changing over time? If your original idea hasn't changed, developed and iterated over weeks or months or years, then really that's a proxy for me saying that you're not learning anything and any good idea should change and grow over time. So your. The question before you write code is, did you change your product idea at least two times?
And did you do that on the basis of learning and discovering what your customers wanted? Okay, that's number one. Number two, have you actually gone out and, heaven forbid, talk to real customers? Step one in that would be to do some quick surveys and use tools like type. Survey Monkey, have you actually surveyed at least 50 of your customers to verify that your product is actually doing the job to be done that it addresses?
Is that is that really reflective of the pains that they experience and the gains that they're looking for? So have you actually talked? Have you actually surveyed 50 customers to confirm that you're actually solving a problem that they want to have? All right, moving right along. The next one here is, did you do one-on-one interviews with at least 10 of your customers?
This is a bit different to the surveys that I just mentioned. In these interviews, you should be really looking to understand their behaviours and their motivations, and you're really trying to understand how your solution fits into them. If you haven't done ten user interviews prior to coding, you're wasting your time with your development.
All right. Now that you're building a really good image of what your customers need, you should prototype it. You can use paper pens; you name it, stickies. You can use it on a whiteboard. You can even prototype with tools like Envision Adobe xd. But these are ways of not having to write code and testing your idea.
You can actually create something that really feels. Your final product or service, your final app, but have you actually gone and prototyped this with your customers because you would be able to see if are they able to get the task done? Are you actually solving the problem? If you haven't done any prototyping with users before writing code, you are gonna waste a ton of your code.
Next one. You set out on a big mission. This is your company, whether it's a startup or an enterprise. But the real question here is, does what you do with this product, does it really serve the vision of the company? And a vision should always be about. Looking forward to a future state of how you're gonna have an impact on the world and your customers.
You have to really be able to ask yourself, how does this new product or service that we're building serve that? And you should be debating this, and you should be validating this because sometimes you can be a little off track. You can be very far away from your original. So I really suggest that before you write your code, check in on that vision statement and say, are we serving that vision statement?
Is this the best step forward? All right. Here's the next one. Number six. Do you have a clear argument for which horizon your product matches? Sometimes? And this is particularly in the enterprise, your product is like a defensive strategy. That's horizon one. Maybe it's a bit of an expansion, a bit of a growth strategy.
That's horizon two. Where a lot of startups tend to play is horizon three transformations. This is not just creating a new product, but creating a whole new business model. Which one of those are, you prove it and if you're thinking I'm not sure. Go to apollo advisor.com, and check out our academy.
We have a whole course on product discovery that will show you how to actually get into this horizon planning. Number seven, can you argue for industry and consumer trends that your product takes advantage of? Now, here's the really cool thing. You will probably find that there are different trends happening in the business.
By now, pay later. That's been a huge trend.
Microfinancing, that's an example.
Now, on the technology side, if you were to look at finance, definitely like blockchain or contactless payments, those are good examples, but the truly greatest startups and the greatest products, don't just leverage one of those.
They tend to have this trifecta between a consumer trend, a tech trend, and a business. So the big question is what trends are you taking advantage of and can you make a clear, valid, cohesive argument for which trends your product is taking advantage of? Nps, oh my gosh, this is such an important checklist.
Have you examined existing data such as NPS in reviews that are relevant to this use case? For example, if you're an existing enterprise, are you looking at your NPS data as a signal to where you should go? or if you don't have any existing product, go and create an NPS survey of people using the best-case solution as of today.
So if you're re-reinventing the automotive sector, get people's NPS from their current driving experience. This is really powerful data to inform your product. Okay, so you've got this clear idea about what you want to do. the outcome of how you might want to solve a problem. But there are different ways of solving a problem.
And what I would always encourage you to do as a checklist for product discovery is have you truly examined two different ways of solving the same problem? So you might do that in the user interface. You might do that at an application level or even at a data level, regardless of which one of those, it is really important that you.
Sort of an AB test of two different ways of solving the same problem. Cuz you'll be surprised. There are so many ways to create a product and so many different approaches. You should at least have had two that you have compared to make sure the one that you went with is the best. Okay, number 10, we're getting through it.
Did you make a lean canvas? If you dunno about Lean Canvas, head over to apollo advisor.com. We have templates there for you in the product discovery course. But really this is a key thing. You don't have to write a full business plan, but you least need this lean canvas to summarize your approach. And in particular, there are two here on screen that I'd really point out.
Number one. Have you really got a robust, unfair advantage and a unique value proposition? These are really what is going to determine your success above and beyond anything else your capacity to do things differently and uniquely. So make sure you have your lean canvas. Okay, so you're building a team.
It's exciting. You're getting all sorts of creative people, business people, and tech people. The thing is, beyond all of those skills are behaviours. Creating a new product is full of unknowns and requires a really tight working team. So here are my ultimate three things you need when you're recruiting people.
They need to be collaborative and really great communicators. Two, they need to be adaptable. And three, if I was going for anything they are of a growth mindset. They love to continuously learn and improve. So don't just get people who've got skills. Get them with good behaviours too.
Number 12. Did you draft a lean hypothesis? This should come off the back of your lean canvas. This is a testable, precise statement you can break down. If you want to know more about how to do that, head over to apollo advisor.com. Check out the product discovery course. We have a whole bunch of thinking on the lean hypothesis, so do you have one?
Okay. Do you have a clear time-based roadmap for your MVP? Sometimes MVP development can go on and on, and. . You have to be careful about that. Never shipping. It's a huge problem. Make sure your roadmap is really tight and literally make it as lean and as minimum as possible. All right, write down all your learnings so far.
So before you actually build, make sure you write them all down. Think about all the different slight pivots change. Tweaks that you did and why you did them. Imagine that you're writing that for someone who's gonna join the company later. It's a really good exercise to be clear on what you've learned, and as I've said, learning is crucial when you're building a new product.
Okay. Lastly, together with your team, have you actually mapped, outlined and highlighted or flagged the risks that you have in development? For example, development is full of unknowns on technical dependencies, and access to resources. I've got a whole list here. Legal, security, all of these sorts of things that are gonna come up during development.
Have you actually identified them? You're gonna have. You wanna speak to other people who've built SI similar products, but it is crucial because then you don't have those terrible Uhuh moments where you didn't see something coming and it really damages your effort to get live. So make sure you've identified those key challenges you face in development.
All right, that's a really quick tour through our 15 points. I hope you are that much closer to building a killer app, and I want to thank you for joining me on this journey of learning. I hope that you've really got into this idea of product discovery. It's one of the most powerful things you can do to shift from guessing what customers want.
You don't have to guess anymore.
You can actually know what they want, and that helps you in design development, not only to get live but thereafter to grow your product too. So if you want to know more, head over to Apollo advisor dot. We'll see you later.