Category: Return on Investment

App complexity grows over time – but developer retention is usually a few short years. Product Managers need to reduce App complexity to the core features and outsource non-core functions to other products.

In a recent post, we discussed the return on investment of using platforms like Contextual for onboarding, announcements and guidance vs hard-coding.

Whilst hard-coding might be a quick win to create some simple tips, the complexity increases rapidly when you realize the cost of:

• analytics to confirm effectiveness
• targeting to get the right audience and trigger at the right time
• small (or large) changes to the text or images that result in the need for an update.

Most importantly there is the:

a) reduced speed of learning (iterating for increased adoption or engagement)

b) the distraction of hijacking your Developers away from working on product features

The Cost of Technical Debt

When a developer says “goodbye” – you need new or existing developers to cover the code “surface area” of their contribution. Developer retention is a major underestimated consideration for a Product Manager.

When a PM opts to hard-code something non-core in their application, the team is making a commitment to maintaining, enhancing that in the future. Also it’s often the case that old features break when something new changes.

This is one form of technical debt.

Here is what happens: Your genius developer has a lot of intellectual clout and can solve things quickly with their prowess. However, they are so talented that weekly they receive calls from recruiters and eventually they decide that it’s time to make a move.

Because they were fast, sometime the coding methods may have used shortcuts or intimate knowledge of the system that the incoming developer needs to learn. New developers often need 3-6months ramp to be able to understand how things are done.

Don’t code what isn’t core

When using a guidance platform like Contextual, the integration is a few lines of code and then you’ve freed you’re developers to work on key core app features.

Automating onboarding, announcements and guidance is systemised at the no-code level and therefore insulates against staff churn.

What elements are best to hardcode and what should be “bought”?

Product teams always have a backlog of features, fixes, customer requests and re-rewrite/re-factor advocates.

At the same time, customer churn, engagement, monetization are the primary product goals that map to company OKRs. 

We used to hardcode emails, now that would be crazy

Retention-driven growth needs multiple inApp and out-of-band initiatives. One out-of-band example is customer emails (drips, newsletters, transactional).

Back in the 2000s product teams used to get the developers to hardcode their HTML emails. Over time it was realised that this was a huge waste of developer time and stopping them making a better product!

So the craziness stopped and now we have a massive industry of products like Mailchimp, CampaignMonitor, Autopilot, Sendgrid etc etc that full-fill the need far better than any in-house initiative.

Today very few companies would make the “build” decision and prefer to use a SaaS platform product that makes email creation and sending easy – its a no brainer!

Should Apps hardcode inApp engagement?

Moving any task from backlog to sprint should be sanity checked against the one question:

“Is this our core business?”

For most products, if your product needs:

• Guides,
• FAQs,
• Tooltips,
• Announcements,
• Feedback,
• Videos

Then, the answer is NO.

For some companies, for example gaming, every user moment needs to be hardcoded and controlled. The financial stakes for conversion are measured in milliseconds and their ad-spend is huge so they need to capitalize. With tens or hundreds of developers and many millions invested – this is a core competency for the Apps survival.

For most companies, however, the core competency is the functionality of the product and ease of use. As we discussed elsewhere, this is why we discuss a:

1. Feature layer (App Design layer)
2. Engagement layer

The Feature Layer – changes with the speed of sprints. It is owned by the developers and should change slowly.

The Engagement Layer – should iterate rapidly. This is where Product Managers and growth teams can iterate and learn what creates retention and feature usage uplift.

The launch (to customer) cadence for each would look like this.

The Business Case for not hardcoding

Once you start with engagement layer activities you are super-sprinting and measuring much faster than your feature sprints can. You may eventually hardcode something that has been successful using Contextual – giving you more fine-grained control, but you didn’t spend person-months building something that nobody cared about.

This table shows our recommendations when establishing a business case:

1. Stop wasting developer time.
2. Speed up your learning iterations
3. Target and measure users at different phases of the journey – don’t spam everybody with popups and announcements!

Hardcoded	Contextual Platform
With Hardcoding, every single tiny change requires App (web) & Appstore (mobile) releases	With Contextual, changes are instant or scheduled to users ????‍♀️
With Hardcoding, you need to stop developing features ????	With Contextual, you don’t bother developers ???? – keep making your product better!
With Hardcoding, you’d have to code user targeting (yep, more code) ????	With Contextual, audience targeting is point-and-click and real-time ????
With Hardcoding, no analytics ????‍♂️	With Contextual, guide interaction analytics are built-in ????

In a business case, numbers speak louder than words – so contact us if you’d like to make use of our spreadsheet and add your unique numbers and resources.
The spreadsheet isn’t too pretty but its enough to make a data-driven business case.

For your:

a) developers. Some developers have a “not-invented-here” view that is disconnected from commercial reality. Especially with outsourced or offshore contractors, they may have a tendency to want to “build everything” even if the work is demeaning to their talents and time.

b) management – they carry the burden of costs.

You can also point them to this video – in 7 minutes it summarises the points discussed here and may be quick enough for them to review to have an informed conversation.

So, if you need help with your build vs buy decision – either a discussion or quantitative model, hit us up in an email or the chat widget.

You can also fill out a request on the Contact Us page.

To understand what functions the platform provides, check out some of the video examples.

---

Banner image credit: https://corporatefinanceinstitute.com/