Refine & Release

It's been a long week and you've done something very few people ever truly accomplish. You've created an app from the ground up and launched it.

That's amazing, but you're just getting started.

You've entered into a world where nothing is ever truly done. There are bugs to fix, features to implement, new tools to add, and hopefully in the future, new apps to create.

Right now, take a few minutes, bask in the awesomeness of what you did and pat yourself on the back. You deserve it.

Once you're done with that, look to next week because there's a lot more work to do. It's time to refine and release your app, making it look and feel closer and closer to your original vision.

This is where you take all the feedback you got and start reviewing it, looking for common concerns or complaints and building something better.

This is also where you start determining when you stop.

How much good feedback do you need to receive to keep going? When are you willing to throw in the towel and call it a best try?

Now is the time to draw that line so you don't push yourself well past it and waste hours of your time and thousands of your dollars making something work when it isn't going to happen.

Where's the Line?

First thing's first – where is the line? When do you stop working? This is different for everyone, but remember; you need to be realistic about what you can actually get out of your app and what you want to see happen with it.

Your numbers might vary, but the bottom line is that you should have something in mind – don't "guess" on something like this. I guarantee you'll err on the side of killing yourself...or worse, quit before you should.

Quitting is one of the great arts of entrepreneurship – learn how to do it at the right time and you will be successful.

As for feedback, I recommend you look for at least 100 responses to your app. This can be a combination of responses from family, friends, paid users, and paying users.

The goal is to get some good information about how the app works and what people think. If you can't get to 100, consider the next step.

Running Surveys

A survey is a quick way to gauge someone's reaction to your product both at a high level and a hands-on level in which they actually use your software.

If you know you have enough users but can't get enough feedback to make conclusions, a survey gives you a way to prod them into taking action. Here's how to build one.

1. Choose a Survey Service

SurveyMonkey is the standard for this type of thing. It's inexpensive, easy to use, and can be sent to people through multiple channels. If you want to spend absolutely nothing, you can also use a Google Form to run a survey, but this requires that everyone you contact has provided their email address.

2. Determine Your Questions

Figure out what you want to know.

Aim for between 5-10 questions. This is the sweet spot to actually get responses from your users. More and people will either provide short answers or not bother at all. Less and you don't get enough information.

Be specific in your questions too, but don't be afraid to ask subjective questions like "how did you like X?"

At a high level, what you really need to know is:

• What did they like?
• What didn't they like?
• What do they consider "nice to have" and what do they need?

You have a laundry list of new features – figure out what these people actually want to see in the next version.

3. Encourage People to Fill It Out

This is the tough part. You should expect no more than 40% of the people you have contact information for to actually respond to your survey. So you'll need 250 users to realistically get 100 responses.

Do the math and figure out if you're running short – pay the difference on a usability testing site or hire someone through Upwork to run through your app and fill out the survey.

It's worth it to have those 100 responses.

One other quick way to drive heavier engagement is to run a contest. Offer a gift certificate to Amazon or something equally enticing to get people to fill out your survey. It doesn't take much if it's a short survey.

Evaluating Your Feedback

Once you have 100 responses in hand, it's time to take action.

But some of that feedback will be more helpful than other bits. To ensure you don't inject your own bias into reading that feedback, here are some tips for how to approach it:

• Knowing What to Ignore – Avoid making decisions for your app based on anecdotal recommendations. Just because one guy confirms a concern you personally have doesn't make it a priority. Look for trends in the data – that's why you asked 100 people to fill out this survey. Ignore small issues that don’t crop up more than a couple times, hyperbolic complaints or praise, or other concerns that you know are small in scale.
• Create a List of Pros and Cons – Create a list from your feedback that outlines the pros and cons of your software. You already have a sizable feature request list and a bug log that you're working with – use these to guide the priority of those lists.
• Map Out Fixes – From the pros and cons list, pull anything that is mentioned a significant number of times and add it to your bug and feature list. The broken stuff still has priority, but if 40 out of 100 people all asked for the same feature, that might be something you bump to the top of the list when you start injecting new features.

The big obstacle here is creating a feature request list that doesn't lead you down a path of expensive, unnecessary upgrades.

Look out for responses that start with "this would be cool" or "I could see it doing this…" These types of responses are helpful, but rarely necessary.

The goal is to find what people really need vs. what they say they want.

Updating Your App

At this point, you're in a very good position.

You have 100+ user responses to your app. You have a detailed bug log from QA testing. You have usability notes. You have your first customers!

Now it's time to start making updates.

As you go through the update process, you can skip Days 1-4 and go straight to Day 5-7 to repeat those processes.

As you make updates, make sure you continuously log bugs and fixes in your Trello tracking board. Write down new features that people want or that you can think of and maintain a detailed log of what to work on and when you want to tackle it.

Never bite off more than you can chew, but don't do the bare minimum – your users will know it and will tell you.

The focus should always remain on critical fixes and it may take several weeks to get to the point that you're not just fixing big broken bugs. New features are certainly nice, but they can wait until you have the time and money to tackle them.

Refining and Streamlining the Process

Speaking of which, there is a cost involved with each of these iterations. You're going to be paying money (or spending a boat load of time) for every iteration you create.

You want those iterations to pay off, and ideally take less time and less money each time.

To ensure this is the case, set clear benchmarks for what you want to achieve, and by when you want to achieve it.

Specifically, you want to make sure that you're not pouring money down a black hole to make an app that no one is buying better.

At the same time, as you continue improving your software, you should maintain the stuff that will get you new users:

• Influencer outreach
• Blogging
• Social media marketing
• Getting reviews and being interviewed
• Soliciting feedback

If you stop doing this stuff, your app will stop growing in users and you're paying money to upgrade an app that no one is buying.

So, know your goals and consistently evaluate performance to make sure you are actually achieving them.

This process is about honesty. It's about knowing what works, why it works, and when it stops working.

The more honest you are with yourself, and the more direct your approach to the development process, the better you will perform from start to finish.