Reflecting on the Productivity Category

My most recent post on LinkedIn cross-posted here.

————————————

Having spent the last 4 years working in the productivity category, I wanted to share some learnings from the space. Note, everything below is slanted towards an early-stage startup ultimately selling prosumer to SMB.

1/ Individually vs Group Useful
Sometimes called single-player vs multi-player mode but the premise is the same. Is your app useful to the individual or useful to a group (eg workplace).

For example, Asana is useful in a group but not so much as an individual. Evernote is useful to the individual but not so much in a group. Rare apps like Dropbox are both but this is not a requirement. Given that productivity apps typically touch personal data, they are not generally viral. Brainstorm ways to be both individually and group useful.

2/ Direct-to-Prosumer vs Top-Down
Is your app B2C or B2B – the trend is to drive prosumer adoption and then to sell to the SMB. Yammer pioneered this model; Xobni extended this model and in some instances it can even backfire such as when Microsoft asked their employees to uninstall the Xobni plugin.

If your app is direct-to-prosumer, you need to think about whether you can really get to 100s of M of users or 10s of M at a really high price-point. Evernote is probably the best example and is still struggling with accelerating freemium growth.

With SMB deployment, you can charge a higher SAAS price-point plus drive more seats. Ideally, you can achieve this without a sales team like Slack and Github have demonstrated but realistically, you will need an inside sales team and ignoring this reality is why I’ve seen many productivity app developers fail.

3/ Replacing In a Category vs Creating a Category
Are you an app the SMB already pays for or something they don’t yet pay for? Slack, as an example is a new category in that SMBs did not previously pay for chat. However, if are a “Todo” app, you are probably competing with an already existing tool such a Jira that the SMB pays for. Getting a company to switch tools is hard and thus why I recommend targeting super-SMBs when replacing in a category.

4/ Create Lock-In
Most productivity apps aggregate some cloud data (files, CRM etc). In the PIM (email, calendar, address book) category, we aggregated email accounts (Google, Exchange, iCloud). Being an aggregator means we are the presentation layer. But without any content exclusively stored in our system, the user can switch presentation layers without penalty.

To create lock-in, some options:
(a) Store some content exclusively
(b) Require upfront customization such as Salesforce
(c) Introduce paid; this will be the best thing you can ever do and will improve all of your metrics
(d) Achieve network effect. Hard to pull of but if you get it, hold on to it!

5/ Be Pervasive
Productivity is a lifestyle and is integrated across personal and work. Although mobile-first is my recommendation, don’t discount laptop usage at the workplace. Apps must be avail on all screens otherwise you are destined to fail.

6/ Have a Macro Thesis
Product management in productivity is hard – there is no 80/20. Workflows are unique to each individual and attempting to change and behave like a coach is exceptionally hard except when managed down (eg everyone has to use Expensify). It’s best to embrace the existing workflow and improve while also maintaining a macro product thesis. Without a thesis, your resultant app will look like the Settings dialogue in Office.

7/ Don’t Be Too Smart
As I’ve written previously, I believe predictive intelligence will be a new layer on all apps. But in the productivity, trust is always the #1 feature. Failing to sync an email will be an immediate deal-breaker. Optimize on precision (accuracy) vs recall (# of results) and ask the user when unsure versus being too smart. Although most contact mergers are pretty good, the 1 out of 10 times they fail is why many don’t embrace.

Network Responsibility

In the past 6 months, I’ve seen more and more infrastructure companies focused on network data optimization (and why shouldn’t they be with video consumption continuing to explode and now representing 40% of all data load). On the other hand, from an operator perspective, the introduction of data caps in creates the downside protection they need (eg if someone is being data abusive, they are paying a significant premium for it) – not a bad situation for the operator.

That being said, what I haven’t found much focus on is the shift of data consumption responsibility to the developer. Developers need to build network-efficient applications and unfortunately, I still haven’t found a best practices / guidelines for developers to adhere to.

I’m definitely not a network expert but certainly developers should keep in mind the following:

1. Chatty vs queued (I’ve heard that the opening/closing of network connections causes unnecessary pain; developers can design around this?)
2. WiFi vs 3G (It’s not difficult to determine network speed and then determine whether to do the “large” or “small” download. This is similar to how in prepaid days, apps may wait until nighttime to download data because of the cheaper tariffs)
3. Roaming or not (This would require network APIs to be available but assuming it is, this would absolutely impact when the application should be transmitting data)
4. Load on the network (Again, this would require network APIs, but knowing load can be used to a developers advantage)
5. Compressed vs uncompressed (Many argue that the PC resulted in inefficient app development and mobile made you efficient again with limited storage/memory/CPU etc. Now that mobile is the new PC, that may be happening again. If you have a server-based application, why not compress?)

And the list goes on…

Operators need to put more pressure on developers in writing network-efficient apps rather than pushing data caps, IMO. Let me know if anyone finds a list of best practices?