Totally A Thing

Engineers love to deal in absolutes. We are trained for it, when we study mathematics, electronics and disciplines like finite element analysis or software development at University. It seems to us like everything in the world can be reduced to ones-and-zeroes, true and false.

Business is not like that. You have to prioritise. It is a constant balancing act. Every time you choose to execute on an initiative, there is an opportunity cost. The time you spent on those cool infrastructure as code scripts is time you did not spend delivering the incremental login feature that your customers needed.

So how do you as a technical leader — say a CTO — explain or understand this balancing act, and make sure your startup or scale up survives? You can say:

Never let the perfect be the enemy of the good enough.

Or:

The practical solution that shipped is better than the ideal solution that didn’t.

The next level up the mastery tree is the deeper knowledge that these ideas are not about compromising. Those trite aphorisms leave engineers thinking they are being asked to lower quality to get a delivery out.

Great technical leadership understands that Worse is Better actually means a “worse” solution is often a superior option. That’s what I hope to show in this article. The “compromising on quality” argument is a complete red-herring because quality is orthogonal to this issue of what a “worse” solution really means.

Huh? Its not about quality? Well what does “worse” mean then?

Can’t we just leave our engineers to do the “right thing” when it comes to building the tech that our startup business needs?

In a business, especially a startup, if the time you are spending is gone in satisfying some engineering driven pursuit instead of a customer need you are soon dead in the water. Money burns away. It goes in no time flat when you’re paying engineers. At your startup do resource intensive technical tasks win out over business realities on a daily basis? There’s a risk that it becomes a culture and a glide path to failure.

Do resource intensive technical tasks in your startup win out over business realities on a daily basis?

Can a startup be fun for the makers? Sure. There’s exciting moments. Is it a chance to indulge technical ambitions? There’s chances for that. But I have run several startup businesses, and when you have staff that you have to pay it gets real. As a tech founder you write code during the week, and on the weekend you have to do payroll. People rely on their pay to make rent or mortgage payments, and to keep their kids in school.

For those in technical leadership right now who may be scoffing and thinking “well, if you’re out of money then all bets are off — this has nothing to do with me” have another look at what technical decisions are costing. As a technical leader what could you do to reduce waste?

As a startup your cash-burn rate, and ability to make payroll is what gives you a runway. That runway is a hard stop. If you are financially headed straight for the tarmac at a hundred-miles an hour it doesn’t help if your test code-coverage is 82%. Cash in the bank is hard number that you cannot argue with no matter how much you love functional programming or clean code.

Cash in the bank is hard number that you cannot argue with no matter how much you love functional programming or clean code.

So as technical leader how do you explain to your engineers this fact? The fact that when the bottom-of-the-barrel is reached they don’t get paid and the company has to shut its doors?

Unless they’ve been through the experience of a startup or of a too-big-to-fail company failure — like RIM or the one I experienced at Nokia — they struggle to wrap their brain around that idea. Surely if I keep showing up at work, the tables and chairs are here, the coffee machine still works, I still get paid. Right?

Strawmen of Worse is Better

Enter “Worse is Better”. Its a critical plank of Senior Engineering skill that you need to master in order to lead teams in a startup or innovative business. It can help explain to engineers how to get on board with balancing competing priorities.

But it does not mean compromising your ethical principles. It does not mean accepting inferior quality. Folks who do not have a growth mindset want to avoid change, and may make these straw men arguments.

Worse is better means: rejection of complexity, even when complexity is the more theoretically correct approach.

Worse is better means: rejection of complexity, even when complexity is the more theoretically correct approach.

But the moment my fellow engineers are asked to choose simplicity instead of some high-priest holy-notion of engineering they react as though it’s the end of the world.

Some are even ready to slap their resignation on the table and walk out. Here’s some ideas that engineers I’ve met are ready to die for:

* clean code

* secure code

* infrastructure as code

* open source

* test coverage

* functional programming

* css in code

* css outside of code

And when I say “ready to die for” I mean it. They’ll shout and threaten to resign when 80% of the code base is open-source/test-covered/functional/clean/inside/outside and they’re asked to make a change to their code base making it only 70% of the previous figure.

“It’s a slippery slope! I’ll resign!!” they say. Usually because whatever the issue is relates to some past war they fought, and they’re still nursing that pain from those days. When an idea that we hold dear is challenged and it’s shown there are cheaper, simpler ways that work just as well for customers it’s tough to deal with.

These principles above like clean code, are important, but they are not absolutes. They are principles that inform decisions. We don’t get to throw the baby out with the bathwater. We don’t get to storm off because a pet engineering hobby-horse is not pandered to. The hubris of engineers can drive a company into bankruptcy and we need to understand the cost of standing on gold-plated principles.

Survival Means Living to Make a Difference

There is a million ways to misinterpret and argue against “worse is better”. Most of the arguments against it that proliferate on the web mischaracterise what its framers intended. For the record the article by Jeff Attwood in his blog “Coding Horror” shows what I mean by the framers. Attwood along with Joel Spolsky founded Stack Overflow.

The thing is that even if their straw-men arguments were true, taking a general approach of balancing engineering high-priesthood demands with what customers will pay for is the only thing that will make your startup survive. Embracing worse is better doesn’t mean throwing out engineering principles, it means feeding them into decision making.

But by characterising it as a choice about quality, by creating a straw-man they can take their righteous indignation all the way to the tech graveyard. They get to die on their hill, and then once the business is shuttered they can go on to some new company. Attwood points to this quote: worse-is-better, even in its straw-man form, has better survivalcharacteristics than the-right-thing and it is spot on.

worse-is-better, even in its strawman form, has better survival characteristics than the-right-thing

See the post by Jeff Attwood blog post quoted above. I hope I don’t need to point out how good survival is.

Survival: that is the one where you don’t die. You make payroll and don’t have to close the company down, and tell everyone you employed that they are out of a job.

A Concrete but Ethereal Example

I’ve found through experience that once you try to get engineers to even question their cherished holy-notions long enough to notice that they’re driving the company into bankruptcy, you start an intellectual fight that is likely to lose people, without getting engineers to realise that even if they are technically right they’re in practical term…

Why?

In my previous talks on how to build an app I’ve discussed source control briefly. Github, owned by Microsoft, is probably the most popular cloud service for source control. OK, but how does that help me?

If your app based startup is going great, then your team will be implementing product features and code for that will be going into your source control system many times a day.

But what about if something is going wrong? How can you check up on that? Do you wait for your engineering team to tell you? I’ve talked about the problems a startup can have, especially in that first app building phase, and especially if there’s poor engagement between the founders and the team:

* My developer left me / Get the Code

* How Does my App Work as a Business / Code Repo: Core to Automation

* How to Build an App / Backlog, Doing Done 

I’ve done to death the “Why” of being a founder who understands how to find the code. In this session I am going to look at the “What” and then the “How”.

If my business was a sandwich bar or a t-shirt printer I could go down to the kitchen or down to the factory floor.

But if source control is a mystery you need to take some time out to decode that, because it's the one thing that keeps your business running. 

What

In the next 10 minutes I’m going to show you what source control might look like, and give you an idea of how it works. Finally I’ll wrap up with a short list of next steps to give you as an appreneur to get ongoing insight into your project so you can work with your team collaboratively.

As a bonus, if you’re an engineer you’ll see the way I work with Git on the command line and you will likely discover something new. 

For non-tech Appreneurs trying to get a handle on source control can be tricky. 

Think of the difference between a document on your local computer or phone, like say a PDF you downloaded; and an email. You know where that PDF is, it's in your Downloads folder. Now compare that with your emails that you read on your phone or computer. Where are those exactly?

A code repository is a bit more like that. In the cloud, synced locally. Kind of.

But another big difference, and it's what I’m focussing on in this session, is a code repository for your project is built in small steps. And source control is designed with that in mind.

Demo of Git

First we’re going to look at a couple of projects from the Engineer perspective and you’re going to see how I would explore code, download it, make changes to it and then update those changes to our cloud - to the Github repository.

Let’s look at a project I started some years ago. This is an app written in C++ that runs on Mac, Windows and Linux. 

It’s stored in a source control repository, and then pulled down locally. That project is private, and only accessible if logged on and allowed access.

Another project of mine is open source and is publicly available for view.

# Pull down the project from github

Signed Commits

* https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-commits

As an engineer I can sign my commits so that you know they are done by me. This is an added layer of security and it's worth doing to ensure that code is being modified by who you think it is.

What if you had a disgruntled employee – call them Joe – who left and decided to put a back door in your code? As long as Joe doesn’t have access to the local GPG keys that your existing engineers have on their computers you can see that all any changes are by legitimate folks with access to the code.

It’s possible to have Github reject unsigned changes but that’s not something I have seen on any repo, and I would not recommend it.

The Git Log

Git never forgets. At least you have to do a lot of work to make it forget, which for all practical purposes is the same. In this article I go through what is required to make Git forget and its a nuclear option - generally you never do this.

* Make Git Forget

The How

* Make sure you have your own account 

* on Github, Bitbucket or whatever system is being used for source control.

* NOT the user name and password of someone else's account or of a jointly used generic account.

* As founder and one of the owners of the company get admin rights to the repo

* You will use this access very wisely, very carefully

* It's generally not easy to inadvertently change anything on Github.

* If you need to appoint someone new to work on the repository you need to have the power to do that, if key personnel leave.

* This is really important: if you get some other account and have the password, it can easily be deleted by that other person who has access to it, or the admin rights revoked. Imagine - some people have left the company and you go to use the username and password to get your project back on the road again, only to find it was owned by someone else. And now it's gone.

* Regularly, ideally after a release or a sprint cycle.

* Log on to github and navigate to the list of commits. If your team is using PR’s then check those too.

* Look for the following:

* Commit messages - should be descriptive

* Commits / PR’s should be small

* Names of files that are edited

* Signed commits

* For extra credit:

* Documentation

* Function names

* Signs of 3rd party or cut-n-pasted code

* What dependencies are introduced?

* The goal is to better understand the pressures and work load of your engineering team. If you are an engineer yourself then reviewing the code others are writing is important.

* You don’t need to introduce PR’s and slow down development to have code review, just read code together

* Ask:

* From the commit messages and files touched is it clear what the change is doing? Is this change improving the product and moving forward the goals of the team and the product?

* Are there signs of technical debt being introduced - for example is code being commented out, instead of deleted? Is the word “temporary fix” and “hack” being over-used to apologise for code. You can ask the engineers to explain what they meant in a non-blaming way.

* Are there signs of churn or spats between developers being fought out in the code base - changes done and then undone.

Totally a Thing is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.

Google’s AI Preview is driving me insane!

I just want web pages!

Instead when I type a search, what happens? It thinks for a moment or two, then produces this bargain basement guess, summarised from whatever blended together soup of opinions it found on the web.

I don’t want that! I never asked for that!!

When I’m researching for my writing I need the actual facts. Many topics are highly dependent on the source.

Google, why do you grind off the serial numbers and sell me this crappy, high-school student answer?

Who ever asked for this?

Searching for a Fix

Well, I finally got annoyed enough to go looking for a fix. 

Seems like plenty of other folks are like me. Tom’s Hardware has an article about a Chrome Plugin called Bye, Bye Google AI. It also lists one called Hide Google AI Overview. 

That second one sounds more technically accurate, as far as the name goes - but I like Bye Bye Google AI better. 

But I’m not going to install either of them, because although I use Chrome for development - that is testing my code - I use Safari on my Mac when I’m researching. 

I use Safari a Lot

Safari blocks a lot of trackers and privacy invading cookies for me without having to install and keep up to date a bunch of plugins that might have security issues of their own.

I enjoy making web developers stop being lazy and actually build their products properly so that they work with Safari as well as Chrome. Another great benefit of using Safari.

Plus it’s also the same browser I have on my iPhone, and I like the synchronization.

So here’s how I fixed my Google AI Preview problem. I just pressed command-comma to open the settings panel, and then, changed the search engine to Duck-Duck-Go.

So I’m being tongue in cheek here. I fixed the problem by getting rid of Google.

But seriously - isn’t it time?

Totally a Thing is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.

There’s some really great apps in the App Store and Google play store!

When I was consulting, building apps for people in business, they’d show me Augmented Reality apps like Pokemon Go, or the Uber app with its live location tracking and ask “Can I get an app like that for my business?”

Welcome to the second post in my series on team dynamics. Last time I talked about communication and how it’s the best bang for your buck when it comes to solving issues that crop up in your app based start up. 

I talked about how teams at any given time have a set level of competency which is not quickly changed. And I went on to cover how trying to motivate your team with pep talks, or worse brow beating doesn’t get to the root of actual problems.

In the previous lecture, I presented the triangle model showing that motivation and competence have a role to play in the throughput of the team, but it’s communication that is the base of that triangle, and it often winds up being the limiting factor.

So motivation and competence are important, when managed at the right time. It's just that when an issue arises is usually the wrong time.

An Anti-Pattern in Team Dynamics

In this session, I want to look at an anti-pattern. This is a tech team dynamics misstep that  nearly always will derail high-performance teams on a project.

When someone new has leadership responsibilities in an app start up team at the start they wind up flying by the seat of their pants. I don’t want to discount the importance of being authentic or of going with the gut.

But it’s good to train those instincts. Get ahead of the game by learning effective strategies for communication so that when the pressure is on, we find ourselves responding in a solution focused way.

The Flaming Limousine

Imagine you are riding down the highway in the back-seat of a luxury limousine. 

But it seems out of control, it’s slamming into the guard rails and flames are pouring out from under the hood. So you call out:

“Hey, it’s on fire!”

But instead of listening to what you’re saying, the driver says:“What’s your problem! You’re in a luxury limousine!”

You say “Watch out, we’re slamming into the guard rails!”

But the driver says: “Stop complaining and have another drink from the mini bar.”

As a team member, you know your team has become a flaming limousine when your accurate observations about actionable issues are written off by referring to company perks, or workplace culture. 

When is it a Flaming Limousine?

Remember the celebration we just had for the last milestone - I can’t believe you’re complaining already.

We are a huge supporter of that idea here at Company X - what’s your problem? 

In a flaming limousine team serious concerns are - by implication - dismissed as being self-serving complaints. 

Signals from the team about important information are missed, and the project is impacted by risks that could have been avoided.

For a new app startup, it's difficult to manage input from the team when it challenges traditional lines of communication. It's even more difficult for folks new to leadership, or at least new to app startup decision making, when problems are pointed out at a time the team is not ready or not resourced to deal with them.

What to do Instead?

So how do you manage this input effectively?

Do you treat the information as a brush fire that you need to hose down, or as a challenge to team structures that need to be realigned?

Those are flaming limousine responses.

Do you have more beer on Friday night, and buy your team a foosball table or basketball hoop?

Sure it's nice to do those things, but it’s not addressing the burning issue the team member is raising. Do those things to celebrate real fixes.

The most important skills to avoid becoming a flaming limousine are active listening, note taking, team dynamics and prioritisation.

Active Listening

First employ active listening to make sure you reflect back to the team members with the information what you are hearing. Always do this, even if you feel it risks derailing the current team ritual, meeting or cadence.

When listening, make sure that everyone in the team who wants to speak is heard without anyone interrupting. That includes you.

However they must be succinct. And once someone has spoken, the chance to speak moves on. When employing active listening to reflect back what you have heard, as a leader, summarise fairly, get in their shoes, and try to understand what they are saying the stakes are. Why is it important? What is the priority?

Note-taking

All this can be done quickly. It does not need to derail the current meeting. Use your notetaking to ensure you capture what you understand. 

If this current meeting or ritual is the correct place for the issue to be resolved, then do that right away. Otherwise, you can ask the person who bought the issue up to create a meeting at the earliest opportunity that matches the priority. The person should also check in with the participants in a written form, prior to the new meeting with a 1-pager on the background.

Team Dynamics

Sometimes drawing up the 1-pager helps resolve the issue before the meeting takes place. In fact a useful approach here is to have the person calendarise the meeting, but if the matter can be resolved before then, the meeting can be called off. 

However the meeting date serves as a forcing factor to ensure it's dealt with - and your team will build trust that you’re actioning the issue.

If the team members respect each other’s contribution that approach should avoid the issue derailing the current meeting. In a later session I plan to cover respecting team members' knowledge.

But if it's necessary - maybe canceling the current meeting and dealing with the issue straight away is the right thing to do.

Prioritisation 

A very useful document to deal with the kinds of issues I’m talking about here is RAIDS - the risks, assumptions, issues and dependencies log. This is usually a wiki page for the project, where emerging problems can be tracked, and all the team members can see what resolutions were. Each line item should show a short normative name, description, date, who it was raised by, and what the final resolution was. 

If a line item in the RAIDS document is too complex to be properly described, create a Solutions Options document, or a High Level Design document, and link to it from the RAIDS line item.

Whatever is actually done with issues raised by the team members, the vital first step is listening in the appropriate way, and capturing enough information to determine the priority. Then you can take steps to make the right forum, and right time to handle it correctly. 

Sometimes listening and recording is enough. Especially when you have the trust of the team.

TLDR

But whatever you do, avoid falling into the trap of thinking team members' concerns are just a complaint to be dismissed. 

Company culture or office perks are not a replacement for ethical behaviour, and sound team dynamics.

This is the fifth post in my series how to build an app. We’ve already covered how to get your team together, shape up a product and build an app. But when that app and our team is working together as a business what does it look like?

Milestone Release. Are We Done?

When the team has been pushing for a milestone, and it comes to release, there's pressure to ramp up marketing and cut development costs.

In an app startup development costs, engineering costs in particular are one of the biggest. But the capability of the engineering operation is the thing that lets the business move forward.

The business cannot operate, make any changes to the product without engineers. So what is it that the engineering team does?

When developers write their code, as I mentioned in earlier posts they work to create an app package which can be installed on the device — the iPhone or android phone. That package can also be uploaded to the App Store or Google play store.

Code Repo: Core to Automation

In reality the process is a little bit different from that. Yes, developers can write code locally, and then push it straight to the stores.

For a release however, usually the cloud store where the code is placed — that’s our repo — is configured to automatically generate the package. It can be even configured to automatically push the package into the App Store and Google Play store.

Actually its more accurate to say its a special cloud-based app, called a Continuous Integration system (CI system)that automatically tests the code, then generates the app from the repo. But it is the repo typically that holds all the code for the build, contains the versioning details, and nowadays even holds the scripts for the CI system.

So to keep it simple think of your repo as not just a store for you apps code, but also the core of your app building process cycle.

Like a Version?

What’s even more interesting about the repo is that it’s not just a collection of all of the code that your developers have written for you. The repo is versioned. I alluded to this already in the previous section. Its these new version numbers that play a critical role in making frequent app releases.

What this versioning means is that if something breaks in your app the repo can be cranked back to a previous version. One that we know worked okay.

Repository Data lives in the Cloud

If you hear names like “GitHub” and “BitBucket”, that is your repo they’re talking about. You want to make sure you have the passwords or keys to access it & administer it.

Second we have the App Store & Google play store where packages are pushed to. And that’s in the cloud too. You need passwords to access those too.

Repository: Holds code, versions it, secures it, and drives releasing an app to the stores. Make sure you have passwords to it.

What you can take from this is the general idea that several cloud-based systems are all working together, like a well-oiled machine, to process the the code and other outputs from the people in your app development team.

That system culminates in the App Store and Google Play store, but it starts with your cloud based code repo.

So when you think about what you get if someone builds you an app, it’s the keys to that repo that you want. It’s the goose that lays the golden eggs. Or at least lays the new updated versions of your app that you’re going to want down the track.

What Happens with Updates?

Now, once your customers download a new version of your app, they can open it up and the app and connect to cloud services to access additional functionality. We discussed this briefly in the previous posts on How Apps Work.

Let’s have a really good think about app updates (made by your development team); and about updates to the items that appear in your app (like services or menu items, or clothes for sale).

A customer may access a product for sale inside of your app, and complete a transaction to order that product to be delivered.

For this to work the app will probably need to contact a store API to check that there is sufficient inventory of the product to fulfil the order, collect the customers details, and then connect the customer to a banking API provided by your e-commerce solution.

So that is in a for-instance internet store app:

* Your online storefront (a web-app)

* Product fulfilment (drop-shipping or inventory)

* Banking or e-commerce (PayPal or Stripe)

* CRM system for customers details (Zoho or Hubspot)

What if one of these four change? You release a new app version right?

But unlike the web, your apps update when a new version is released to the App Store and installed by your customers. So you need for the old and the new version to work with all of the above services.

You’ll have customers out there with the old version of the app. Maybe for quite some time. They may just choose not to update. You at least need to not crash the app, and display some useful message like “Please update”.

Cloud or In-App?

Let’s say you manage digital for a small food chain. You have maybe a dozen restaurants in the country. And let’s say you update your menu.

You as a business app product owner may access your web-app, and update your restaurant menu in response to recent changes. Then submit those changes so the new menu goes live.

So where does the menu live? Cloud, or in-app?

If its in the cloud only — say via a hybrid app web-view, then customers who don’t have internet at the time they check your app cannot see the menu.

But if its on the phone only it makes your app downloads bigger, and you need to make an app update, just to change your menu.

In reality a good design might be to have it in the cloud, with a local cache, and a default that is installed with the app. So it’s in both places.

Stock in Trade

In your business what is providing value might be physical things you’re selling as items. Or it might be posts and reviews to your pet-minding or childcare app. Whatever they are, these items are your business to care about, if your customer is to succeed and lead to your app success.

What does all this mean from the point of view of your business?

It means that you really need to think about items that are going to appear in your app. Think about those items as part of a task it’s going to be completed by your customer — like viewing a menu, or a review.

And when you think about it, decide which details of the items have to be in the code and be shipped as part of the app. That details will be shipped to every single phone that has the app installed.

Also think which other parts will need to be live in the cloud and will need to be connected to and updated when the app is actually used.

Often the best way to visualise this is with detailed User Experience flows.

Alternatively there might be best practice for the stores or back-end API’s that you are using. So you might use a dedicated review site API. Either way you’ll need to think about where the information about those items is stored.

Viewing and Updating: Two Different Customer Tasks

Think about a case of products that are ordered in an app. In this example case only the cloud that the phone app connected to knew about the details of the products. But the app needs to know how to display them once it gets from the cloud the list of products that were available.

One pattern I have implemented for an app with In-App Purchases is to have 7 items that comprise the purchasable products. These 7 items are coded into the app, along with a name, description, category, price and photo. The app knows how to display all of these things in either a detail view for the item, or in a list of all items.

Let’s imagine one item is not …

Imagine the throughput of your team is defined by this triangle - in this model the sides remain in constant proportion.

Once you have hired someone competence is fixed. Lets assume you have a team and you want to make the best of them.

Motivation - the mistake some leaders make is thinking what they have to do to get their team producing output is to crank up the motivation. Introduce crunch time, do pep talks.

But in my experience its the communication which winds up being the restricting factor MOST often. If you improve communication then you will begin to reach the potential of the motivated competent team.

The job of a leader is to:

* filter outside impacts that can derail the team,

* simplify the view they have of the overall product and

* provide a compass set on true north.

* Provide a consistent drum-beat that gives the project a cadence.

Technical projects have failures most often from a lack of shared understanding. The best bang for your buck as a project lead, for improving team performance, is time spent on communication.

If there is an issue, seek information, understand why things went wrong, and open up communication lines with your team. Hiring 10 x engineers does not work. Pep-talks and brow-beating doesn’t get to the root of the problem.

In this model, the throughput — the performance — of the team is limited by the smallest of the three sides, so communication more often than not is the low hanging fruit. Try that first because a fix to a hiring problem could be a long way off. Issues with motivation — if real — aren’t going to get fixed with fire-and-brimstone speeches.

Ask open ended questions, and guide your team to the solutions & work with them so you can discover the facts, and the actions that led to the issue.

Look at onboarding procedures, how work is managed and how UX specifications are updated over time. Hunt down the miscommunication bug-bears and work with the team to slay them.

Improving communication will provide a team with good motivation and competent members with the best chance of performing well.

In this episode the rubber hits the road and our app is being put to the test. Will it succeed or fail? To get to this point an appreneur — either an app-based startup, or an existing business creating an app — should already have things sorted, as laid out in previous episodes:

* Business plan with fixed and growing costs, unique value and revenue

* Product tested by selling value via a duct-taped together MVP

* A basic understanding of what apps are, the risks and how to avoid them

Money is one measure of success. Think about what success means for you. I’ll assume at least you want folks using the app, right?

Let’s jump right in.

Start with your customers. What do they want to do?

Working with your UX designer, and your product owner, answer this question: what are my customers trying to achieve?

How your app succeeds starts with Jobs to be Done:

Jay, an office worker, wants to eat healthier & searches for meal plans

Here wants to eat healthier might be unrelated to your business about recipe sharing with online ordering, but let’s say your app can help Jay search for meal plans and has filtering for healthy options.

The search is a task in your app, that helps toward a goal.

I saw founders struggling with apps because they have a lot of functionality that they want to put in — especially if they have a website full of stuff — once they start building an app the first thing they want to do is cram all of that in. Shoehorn their website into the mobile user experience. Successful apps are the ones that work for what customers want to do.

Successful apps are the ones that work for what customers want to do.

They don’t want AI, they don’t want 256bit encryption, they don’t want a laundry list of obscure features. They want easy meals they can eat. They want to find a nanny they can trust.

The Jobs to be Done framework and also Persona creation will help a Product Owner home in on this.

Monetisation in Apps

In the initial App Store gold rush in 2010 onward, we got what I’m going to call “Classic Apps”, like Instagram & the app then known as Twitter. Instagram happened because we all have a camera in our pocket now. Twitter was invented because we were OK with texting on our phone. They’re known as phone apps, but have web presences as well.

Note: when I say “inside the app” or “on the phone” remember apps these days are part of the fabric of the internet. I mean the whole app platform.

We are also familiar with mobile games like Candy Crush, or apps such as Duolingo that teaches you languages. Here the value that lures the folks to the platform is some in-app offering — like learning a language, or playing a game.

Often these kinds of apps have known, logged in users who see advertisements that the platform shows to them. These users are valuable to advertisers.

Free to Play Apps

What’s common to these apps is they make money because the actual app itself has some value that it delivers to its users — learn a language, share a photo.

Free apps generate revenue from the app directly. They survive by acquiring a wide funnel of incoming users, retaining and monetising them.

The critical strategy for this kind of free app — and I include freemium here — is to have a wide funnel of incoming users, who go through the classic cycle of acquisition, retention and monetisation.

It’s very common to have the customers pay for that value by ingesting advertisements. Other possibilities are subscriptions with a free month, which have become hugely popular, and in-app economies, like Trello Gold or Gems.

Premium Apps

In some classic apps customers can upgrade from the free to the premium version by completing an in-app purchase, or by buying the premium app in the App Store.

The reality is that app pricing is a race to the bottom, with everyone searching for “free” solutions for almost every niche. That free-to-play funnel keeps gobbling up all the customers and making it hard to break in with a premium app.

It is possible with an excellent app, to win via App Store listings and positive reviews. Procreate — an app for digital art with the Apple Pencil — is a good example of a premium app that is successful.

Monetisation outside of Apps

Apps also can make money indirectly, by speeding up, enabling and making more ubiquitous the every day actions involved in business. Apps like Uber, AirBnb and Airtasker enable us to pay for services like transport or a home handyman. We think of AirBnb as an app but these are business transactions using an app as a channel.

The local government, the tax office, post office and big corporations like Facebook and Google often have apps to help folks engage with various parts of the business.

Smaller businesses often use web apps to manage restaurant menus, online stores and appointment bookings. What all these apps have in common, where the folks interact directly or indirectly with the business, is that tasks are at the core of success for these apps.

Success flows if Tasks are Completed

Let’s imagine your business has a special promotion for summer or winter or some new seasonal holiday, and you send out promo codes to your customers to take advantage of the offer. A task would be for a customer to take that code, shop on your app, and apply the code to their account.

The most important thing with tasks is that even if a customer can get almost all the way through the task, if they can’t complete it then you don’t make that sale. It might not be a literal sale, but it’s some interaction where the customer receives value, and engages with your business.

During the app development process, each iteration, the product owner is checking tasks can be completed inside of the app. If a feature is built by the engineers, that is verified by trying it out in the app.

Rule Number One for App Monetisation

So here is the first rule for making money from your app: identify the top 3 tasks that you want customers to engage with through your app; then absolutely nail the user experience for those tasks. Ensure that throughout the life of the app those tasks are constantly tested end to end to make sure they work.

Payments inside your app require ensuring trust. Customers will be looking for the hallmarks that let them know their money is safe, and what they are paying for will be received.

To ensure that tasks are working, conduct acceptance testing prior to your release where each step of the end to end task is tested on a phone.

In the case of in-app purchases (IAP’S) the Apple App Store has its own APIs for these which can make these transactions very secure. Likewise Google has its own commerce APIs. Both of these require custom native programming in the app to work.

Apple in particular is a stickler for getting these right. If a customer buys something in your app which they get to keep — for example upgrading to a premium version in the app, then you must provide for restoring that purchase if the app is reinstalled.

Both Google & Apple take a proportion of proceeds, but in return will handle a lot of customer issues such as chargebacks and paying in different currencies. Otherwise you can use a payments provider API.

Retention Rules

The second rule for making money with your app is stickiness. You need to keep your customers in your app. You need to think from their point of view.

On your app website you should have carefully crafted open in app linkage so that customers can continue their transactions from the website into the app. Folks who have downloaded your app should feel like they are special, and that they have special insight, or privileged acce…

In part 1 I looked at the Product Owner and UX Designer. I’m going to jump straight in to the next specialist in the team — the engineering manager. Related roles are team lead, project manager or scrum master. Their job is to resolve problems that may stand in the way of the success of their developers, UX designer and product owner. This person is an …

This is a tie-in for my series on How to Build an App. Please checkout the other posts in that series, but especially the one on App Startup Canvas.

Use the App Startup canvas to define the ground zero for your app development efforts: your team, your expertise, your plan to get revenue that will offset costs.

Listen to the above to understand some important takeaways:

* Your app is at the end of the day a channel - its part of a business

* Vanity metrics don’t beat customers - the ones that pay money

Please also checkout the episodes in the series How to Build an App, or at bare minimum this one on Product Owners and UX Design.

The Pattern that Repeats

When I was building apps for folks in the startup co-working spaces where I sited my engineering consulting business Smithsoft I saw a pattern repeat over and over.

* I have a great idea for an app

* Here’s a pile of money to build it

* When the app is finished

* We’ll make so much money

What happens? What goes wrong?

The folks involved in the app business are working in their day job, maybe they mortgage their house, get a loan or have mom-and-pop investors; but they phone up the app development house that they found on the internet and after months and months when they see the first iterations of the app they get increasingly upset when it doesn’t meet their expectations.

Then they either crash or die.

Die means they never get something they can take to their planned launch, which honestly might be less heart-breaking for them. They write off the money they spent, and go back to their day jobs, but with all their savings or investment burned.

Crash means they put the app out there, and spend more money on marketing, only to find no-one downloads the app, their ideas about what people wanted were not strong enough for anyone to use the app let alone generate revenue from it. Then they are not only in the situation of savings or investment burned, but also massively in debt.

What it Looks Like

A startup is a business founded to handle extreme uncertainty. It can also be a “high-growth” startup, which makes it an investment target, but it doesn’t have to be. And I’d advise against it. As I discuss below, customer money is better than investor money.

The founders get together with their marketing effort and plan out when the app is going to launch. They pin all their hopes on a big marketing splash, with a set of features that they have asked the overseas app development team to build.

It looks like this in their mind:

At the bottom left of this — imagine its a chart with each position being some combination of feature — we have our team jumping on board and digging in for the journey to launch day.

Toward the top right — so the plan goes — actual paying customers will see the list of features in the App Store, after being led there via a marketing campaign, and will download the app and create revenue.

What Actually Happens

Startup means uncertainty.

Let’s imagine a company that doesn’t instantly crash and burn, and has some insights enough to get analytics or market research back about how customers are perceiving the app. They head out with some stake money, and a plan to get to actual paying customers.

You’ll also hear the term product-market-fit or PMF. I prefer the term “paying customers” because an acronym like that rapidly degrades and loses all meaning, just like “minimal viable product” or MVP does. I advise against using PMF - focus on customers.

So what actually happens looks more like this:

* The first course charted is off the mark (unbeknownst to the team) and it seems the app build is not approaching what customers want. Product-market fit is off.

* An investor surfaces, off the starboard bow, and one of the team says “we should hear they have to say” — next minute you change direction chasing money that never appears. Customer money is real, investor promises are not.

* The team course corrects, and is on track toward paying customers when the build runs into regulatory, legal or standards issues that they ought to have forseen but didn’t.

* They’re closer to PMF, but one of the team says AI is everything these days and they need to up their game. They work to cram in some AI features, even though none of the customers asked for this.

It’s at this point that the stake money runs out and you are high and dry. Limp back to port and sell you ship for scrap. If you’re lucky.

This is Fine

No, no it’s not.

But we are working our way to product-market… I mean on our way toward paying customers, right?

Yes, but at what cost?

This is what it looks inside the engine room and wheelhouse.

* The view from the Product Team is limited. They have their feet in the product space and it’s hard to navigate. But they do their best to chart that course.

* Down in the engineering space they are driving forward, but every turn of the screws costs money. Every day that goes past cash burn is eating your chances of success because once the fuel is gone, you’re done.

Here again, is my recent session on Design and Product. These are how to sharpen your team structure so that you have the best eyes up in the wheelhouse.

You will not get investment if you cannot show customers. And if you have customers you don’t need investment. The first time you get customer money — real customers, not someone’s Dad, or that company you used to work for — it will change everything about your app startup plan.

Some folks do break my rule here and manage to persuade investors — angels, or sharks — to invest. Fine.

I was there with my startup. We got investor money. It’s seductive because you think you have time, and can build something and find customers later.

Wrong.

Now you are back working for someone again, because that investor has a lot of control. They can tell you where and when to site your team, what to build and how to market. If it all goes sour, or no customers turn up you still wind up out of pocket, but with a reputation hit, maybe family impacts, health impacts as well.

How to Escape from this Death Spiral

Listen carefully to the messages I have in my presentations. I don’t do this stuff to exercise my jaw. I’m not a “thought leader” or an “influencer” - I’m an engineer. I’m one of the very expensive pieces of the puzzle for getting apps built, and I’ve seen folks follow this pattern over and over.

WRONG: I have a great idea for an app

Ideas are like a*holes - everyone’s got one. Until you make a business plan out of it, it’s worthless.

* Don’t use bad proxies for truth.

* Not: How good it feels, what friends say, what’s trending

* Vanity metrics such as likes or engagement

* Use metrics that include revenue from customers

* In return for actual value that you can explain in a second

Maybe you’re used to fake it until you make it and don’t be a naysayer type messages from every internet based scheme. Look for and listen to good business advice, not glamorous influencers.

Step one is to complete the App Startup Canvas, and make sure you have a business model. Start with the Gaddie Pitch, but don’t stop there. Fill out with your team how you are going to get revenue from customers.

WRONG: Here’s a pile of money to build it

If you throw the app build over the fence to some developer team, your app is guaranteed to fail.

If you throw the app build over the fence … your app is guaranteed to fail.

Because you have no idea where those paying customers are on that feature sea, you cannot succeed unless you are on board. That means being embedded daily in the process. Take on the role of Product Owner, research what that fully means. Or get involved in the other capacities if you have those skills.

But all of you on the founder team needs to be acting as checks and balances. No outsourcing decisions, no leaving important planning to one te…