Don’t ask for an app, ask for a live trial

Do you realise that you can save over 30%-60% of your app investment by NOT asking your app development company to take your app to market?

Getting into learning mode

Let’s say you have a vision for an app that will revolutionise an industry. Or perhaps it will significantly reduce your operating costs. You’re going to want to take that to market, so it’s likely you’ll start phoning app developers, meet with them to see if you get along, and find out how much they’ll charge to take your idea to market.

There are times when going straight to market with your big idea is the right thing to do. It makes sense to take your idea to market and reap the rewards.

The problem is, there are other routes to market that can save time and money, and reduce your risk.

A different approach involves trying out ideas before you pour all your time, money and energy into them. Apps are usually the execution of interesting new ideas. Or, interesting questions as Paul Graham would put it. Those ideas need testing so you can learn. And the whole team needs to be in that frame of mind.

Those ideas need testing so you can learn. And the whole team needs to be in that frame of mind.

Problems with going all-out

If you ask a company to plan to take the product to market, you’re not creating an opportunity for you and your chosen creative team to learn.

You also risk your polarising their thinking toward a big-bang delivery. That means the creative team is going to be in “delivering end product mode” throughout the project. An alternative mode you could put them in is “learning mode”. There’s a big difference.

An alternative mode you could put them in is “learning mode”. There’s a big difference.

For example, one thing that’s affected is how the team estimate the budget needed to deliver your idea. When you ask a company to help you take an idea to market, they’ll start with an estimate of costs and a timeline. The project plan and cost estimates will all be geared up to taking a final project to market based on some specification you’ve given them. If you’re specification changes over time because you realise you hadn’t quite got it right, then the costs will change too. It’s better if the app developer works to a plan that involves testing assumptions early, you’ll get a much more sensible budget.

It’s better if the app developer works to a plan that involves testing assumptions early, you’ll get a much more sensible budget.

In short, nobody wants to start their new venture with an incorrect budget, so consider putting some learning milestones in there. A good first milestone is a live trial.

Why modern teams do it this way

Companies such as Google, Microsoft and pretty much any startup take a different approach. The avoid big-bang launches and instead take small, fast, relatively inexpensive steps to test their ideas and refine their product strategy. This is similar to the scientific method. It works for a number of reasons, to name a few:

Ideas Need Testing

You will have made some assumptions when planning your app idea, and if you’re like most human beings, some of those will not have been validated in all the excitement. For example, Colour spent $41M building an app that assumed customers would use a social network that was only available when friends were in their proximity. It was an expensive assumption that unfortunately didn’t play out well in the real world – and ultimately Colour failed because of it.

Finesse Takes Time

Making an app highly polished and slick is up to 2x-5x more time expensive than creating a first-cut app that simply looks professional. The creative team have to test the app on real people, refine the flow, and visually polish the end result. Polish and slickness are highly important because they increase engagement which ultimately affects your bottom line. However, if you haven’t validated your ideas with a trial, then investing in such polish is like putting your foot on the accelerator too early.

Robustness Is More Expensive

Building a highly robust app is more expensive than building a “test the water” app. Engineers will want to invest time in ensuring your solution can handle large amounts of customers and has failover backups in case of problems at the data centre. They’ll also want to make sure their code is easy to modify in the future.

Changing your plan can speed up execution

If you can appreciate the risks, then you’ll want a company to work with to mitigate these risks to speed up execution and reduce overall required budget and timescales.

To do this you simply introduce a few new learning milestones. These milestones will quick-and-dirty, and get more “serious” as your learning experiments demonstrate what your creating will work.

One way of doing this is to set your first milestone as a live trial.

What is a live trial?

A trial is where you test if your idea works in the real world. It means avoiding taking a complete, fully polished app to market initially. Instead, you build a subset of features and do a limited launch. For example, you could launch your app for a single day to a small cohort of customers. The amount that you’ll learn from doing this is tremendous. More importantly, the whole team (including your creative app team) can benefit from the learning, and incorporate that into the next milestone.

Creating a trial will require a lot less time and money than building a real app. This is good in itself, but the real benefit is that you prove your theories before investing more in your idea. Or even better, learn what changes need making and then improve your product design. So it’s more likely to gain traction and be successful.

By validating your ideas, you only invest in the good stuff. You’re backing the right horse, so to speak. This saves you money in the long run and reduces your spend up front.

Let’s say your idea is to launch an app that lets shoppers ask questions about products they’re looking at in the bricks and mortar store such as Curry’s. They can use the get immediate answers within 5 seconds. For example, whilst considering a purchase in store, one customer might wonder “What is the returns policy?”. They can pull out the app and ask this question, and immediately get an answer. This saves them going to the information desk and queueing, or trying to flag down a member of staff. And, it makes them more likely to buy.

Note: This is just an idea I came up with now, it might be a terrible one!

Designing your Trial

Designing a trial run for your idea should be fairly quick and easy. One way to start is to consider your assumptions, so you can later figure out how to challenge those assumptions in your live trial. Some assumptions for the idea above might be:

• Hypothesis: People want to get answers about products and the brand whilst shopping in-store
• Hypothesis: People are more likely to buy if they can make informed decisions
• Hypothesis: People want to avoid talking to shop-floor sales staff

It’s possible that all these assumptions can be wrong, even though they sound believable. The key is to design a trial that tests the essential validity of your idea, which challenges these assumptions and proves your value hypothesis.

Getting your idea to the trial will require a fraction of the time and money to take a full app to market.

Here’s an example of what a trial for the above idea might look like.

• You research a single high-street store in a single city who is willing trial your idea
• You ask them to incentivise some of their customers to install the app and use it on a single day
• You ask them to arrange for a single staff member to be available to answer questions that come through the app that day
• You run the trial for day, and then study the results, interview customers, etc

The more constraints you can add to your trial, the less investment you’ll need up-front.

Getting to the App Trial

When you start your app project, you can explain your trial objectives to the creative app team. They should be clear on what you’re shooting for, and it’s their job to help you deliver the brief at minimum cost and shortest timeframe. Of course, you can explain the bigger picture, and even ask them to give estimates based on what you know today. Just take those with a pinch of salt.

So, a live trial is easier to estimate and budget for because there are less unknowns.

How does this save money?

In a nutshell, you’re massively reducing the scope of your project. In doing so, you’re reducing the cost and timescales. For example:

• The team can make the app functional and professional, rather than wasting days on highly polished designs
• The “brains” of the app may not need hosting on industrial grade web servers, with failover and backups. They can just use $5 a month hosting for a short amount of time.
• The team won’t need to submit your app to Apple for review, or even put on the app store. They can send it straight to the test cohort.
• The team might only be building a handful of essential features, so there’s much less design, development and testing time.
• Because it’s a trial, the team may have a little freedom to cut corners to save money, as long as it’s a considered decision.

Don’t trust me? Ask your app team to quote both

If you don’t believe what I’m saying here, try asking an app team to quote the full product launch, then ask them to quote taking a live trial to market for test purposes only. The difference will be huge.

Yeah, but won’t we have to invest more money later on?

By building a trial, you’re cutting out a metric ton of work. So the trial itself should require much less investment. Because you’re also investing in learning – i.e. finding things that do and don’t work, you won’t waste money on polishing bad features. You’re saving money by not investing in things that won’t make your product stronger.

You’ll still have to invest beyond the trial, but you won’t waste money on dead ends. And you’ll invest based on solid research.

It’s all about managing risk and evolving an idea until it’s market-fit.

Pocketworks are about de-risking your project

Pocketworks is all about managing your risk when it comes to launching an app. We want you to be successful in the long term. There is a selfish element to this because if you succeed, we believe you’ll want to stick with us for the long term. And we’ll share in your success, creating a win-win relationship.