Product Managers beware App Feature Complexity

When it comes to adding features to your App, Mobile App Product Managers would be millionaires if they got paid each time as opinionated colleague or even the developers said:

“how hard would it be…”

and

“can’t you just…”

I was reading a post from Kris Gale, VP Engineering at Yammer, on the First Round Capital blog about “The One Cost Engineers and Product Managers Don’t Consider”. Kris was saying that Product Managers are the main culprit, but systemically the expectations are much broader, especially in small to medium size/maturity companies. I’ve been in teams of developers where the (awesome) “Product Manager” got the nickname of “Dr No” (punning on the James Bond villain) for fighting against “one more feature”.

The problem for each new feature is the cumulative complexity of:

1. Initial development and QA of the feature
2. Decisions on targeting and visibility of the feature
3. User education about the feature
4. Measurement of uptake/engagement of the feature
5. Fixing bugs and UI improvements for the feature
6. Release management and announcing of bug fixes
7. Skills transfer on staff turnover of developer and QA staff wrt this feature
8. And if you are in an Enterprise:
   • Internal signoff and communication
   • Additional reporting, review for compliance, security
   • Lots of meetings!
   • Education and impact to customer support center
   • Probably greater staff turnover

Contextual gives 3 great benefits to removing complexity:

1. Completely REMOVE the complexity of adding user education to your App. By creating a layer of user communication without code, the Product Managers get autonomy to iterate and experiment without adding to complexity.
2. Reduce the impact of #1, #2, #3, #4, #6 of actually implementing and managing new features.
3. For Enterprises, radically reduce the meetings, reporting, signoff for getting user education done.

So “Contextual” attacks the Progressive Onboarding challenge, not just for new features but deepening engagement for specific existing features that a segment of users have not engaged with.

Here is a great quote from the FR post:

Among the most dangerously unconsidered costs is what I’ve been calling complexity cost. Complexity cost is the debt you accrue by complicating features or technology in order to solve problems. An application that does twenty things is more difficult to refactor than an application that does one thing, so changes to its code will take longer. Sometimes complexity is a necessary cost, but only organizations that fully internalize the concept can hope to prevent runaway spending in this area.

We believe the FR post makes important points from a development manager perspective but discusses one part of the problem: refactoring and engineering debt**. We’ve shown there are other related complexity resource drains that should be costed and solutions found.

You can find the FR article here.

** there is a some UI comments that really can be summarized that Occam’s Razor should be applied go UI decisions.