Developing more profitable apps faster

No one wanted the first three big apps I built, and I was in despair.

Pain is a good teacher. I learned from my mistakes, improved my processes, and built and sold a portfolio of apps of 2 million downloads.

Several clients, big and small, have leveraged my skill set to grow their apps in the same way.

One thing I’ve learned – we’re all destined to make the same mistakes if we’re not careful.

Do any of these problems sound familiar?

If you are:

• Trying to avoid waste in your app development starting NOW
• Want to work through the path of finding revenue & profits and have only months to work with
• Looking for specific step-by-step techniques that have proven to grow apps.
• trying to outrun competition that’s exploded onto the scene

This typically makes you:

✅ Entrepreneur with or without an existing audience
✅ Early-stage founders & or executive
✅ Director of Product/Engineering & Managers who are hoping to expand business through apps

If this is you, aim to avoid the same pitfalls as almost everyone by leveraging this guide.

The processes that actually work are often not the things we think will. We’ll dive into that soon.

Why should I trust this book?

I’m Rob Caraway and I run TrendCraft.

I’ve:

• Built apps from scratch that have over 2 million downloads and have been acquired.
• Grew a client’s mobile business to seven figures.
• Acted as Mobile Lead for several clients including iClicker, HEB, Oracle’s Moat, & Kubota.
• Have run hundreds of app experiments and worked across over 10 industries for over a decade

This is meant to be professional grade – I attempt to avoid speculation, magic bullets, and focus on specific theory, strategy & tactics.

I haven’t gotten to this point without a lot of failures that required a lot of reflection. We can learn from one of my biggest failures: Valt.

What I learned from one of my Biggest Failures: Valt – A password management app

Early in my career, a friend mentioned they need a password manager solution. Looking for ideas, I jumped at the “opportunity” to build her something special.

Excited, I reasearched EVERY current solution available and took note of their problems. I interviewd my friend about her problems a lot. I read all their bad reviews and thought to myself “I can do this better”.

I built an app over the next half year that:

• Had a more attention grabbing app icon
• Was a smoother experience.
• Had a prettier website
• Looked and functioned better

Than any of its competitors.

And yet when I launched it – crickets. Despite being a “better product” than the competitors, very few people wanted to use it.

Why traditional app development doesn’t work for growth

We are rolling the dice when we make assumptions.

Yet that’s what we do with every single app idea, feature, design decision and implementation detail.

With my app Valt, I made a massive amount of devastating assumptions. The biggest one being that users would want to switch or try an unproven competitors because it “looked prettier”.

But “looked prettier” was also entirely subjective.

I thought I’d involved enough feedback from “users”, but those users weren’t users and they were telling me what I wanted to hear.

I hadn’t tested how actual potential customers would actually respond to the app until it was too late.

The more we build before getting into actual users hands, the more we have to test and improve to get it right.

By the time I was getting useful customer feedback, by people who ACTUALLY wanted my app to deliver, it felt like I had to steer a titanic to course correct.

✅ The next app I built, GifShare, I spent one week building an mvp and already had over 500 users signed up ready to use it before it even reached the App Store.

We feel safe because we’ve hired a fantastic team, done hours of research, or even had previous successes that we think will carry over.

The worst part: approaching the problem like this feels intuitive.

But building like this is unfortunately a leap of faith:

• every single feature you add is an assumption your user will want them
• every single UX decision you make is an assumption about behavior
• making your app “pretty” is an assumption your users will also find it pretty

We typically think the risk is not taking time to design a better app with more features than existing competition, but that isn’t true.

So then if this type of building doesn’t work, what will?

A working theory of App Growth Engineering

App Growth Engineering is the pursuit of engineering apps to maximize revenue.

I make several assertions that combine to create a full picture of engineering App Growth.

In order to give ourselves the best chance to maximize revenue, we must:

1. Maximize the Quality of Ideas we work on

Theory: For team N & team M, given that each team executes at the same pace, where team N dedicates deliberate time to processes identifying the best ideas to work on and team M chooses ideas with no process, team N is more likely to create sustainable growth than team M.

In practice, despite the management science being there for years, most app teams simply do not dedicate the right amount of time to picking the right ideas.

The tricky part: we get into trouble dedicating TOO much time to picking ideas – therefore, developing quality ideas faster is our goal.

Everytime I’ve failed to do this (like Valt), it’s costs me big time.

Companies like Pinterest, Spotify and more have realized that we need processes that not to be dedicated to not just generating ideas, but:

• improving the quality of idea generated
• improving the selection process of generated ideas
• improving buy-in to selected ideas from all stakeholders

2. Mitigate Risk and Waste and Maximize Impact with Effective Experiment (or Bet) Design.

*Theory: for teams N and M, where team N measures the amount of effort, risk, and potential
Every thing we do, no matter how informed we think we are, is an experiment or a “Bet” as many have begun calling it, and I will refer to moving forward.

We incur risk and spend with every action we take.

Our hard work and maximized efficiency will mean nothing if we are working on the wrong things, too.

To eliminate these issues, we design experiements (bets) aimed to maximize our chances at working on the highest impact items for our current business situation.

Our Bets should:

• Require the least amount of up front work as we can
• Target users we believe will have the highest motivation to use at first
• Include any risk mitigation strategies (what if those goes horribly wrong?) that would prevent problems a bet might cause
• Have a clear benchmark for what success and failure looks like

3: Mitigate risk and maximize impact by with effective MVP Design

Minimum Viable Product: taking the quickest sustainable path to validating whether any initiative has a chance of adding business value or not.

An initiative might be a new app, new feature, new tweak or new version.

A key word mentioned above is sustainability.

Our projects will fail long term if we are not carefully considering three things:

1. Our we managing tech debt responsibly?
2. Does our tech stack and tooling give us a competitive advantage?
3. Do we have the expertise to deliver the project effectively?

Affordable expertise is the number one concern. Strong experts will know how to manage tech debt and will always be evaluating the tools and tech they use to deliver value.

What is tech debt?

Tech debt is like real debt – building a solution with code that is designed for speed will often bring us tech debt, while spending time designing software well will pay off tech debt.

Having some of it is useful (good debt), as it can help you get something to market faster.

Having too much of it is suffocating and can tank your app business.

4. Improve business value by measuring and obversing the right metrics

We’ll never know what’s working and what’s failing if we aren’t measuring the proper things.

Example: we’ve upgraded to a version 2.0 and our revenue has actually decreased! We aren’t measuring anything however, so we have no choice but to throw out the entire new version :(

In reality, several things of that new version, like onboarding and our core features, actually improve user engagement! The sales page was just converting poorly.

We’ll also think some successes are failures if we’re not measuring the right metrics.

Example: we add a new in app purchase flow and notice over the last week that our revenue has jumped 40%!!

Great news right? Well…

What the metric didn’t take into consideration is some of the new paying users pissed off a lot of users who now won’t be cancelling and will stop using the app earlier than before. Overall, this is a net negative on our business.

Growing our app business relies on us knowing how to measure the right metrics and mitigate the consequences of those metrics.

Finally, Go through each stage with the least amount of time, effort & expense

Staying competitive means a regular evaluation of the tools process
We should constantly be evaluating if the tools, tech, and processes are helping us stay competitive and move faster.

We should always be on the lookout for waste and new advances in automation and speed.

Even the biggest successful bets mean nothing if we aren’t approaching them competitively and sustainably.

#Please sign up here for more update on how to grow apps effectively.

This is version 0.1 of this book. Reach out to me if you’ve got improvements and let’s make it better together.