First page of Discourses by Epictetus
Don’t set your heart on so many things,” says Epictetus. Prioritize. Train your mind to ask: Do I need this thing? What will happen if I do not get it? What if it all happens all at once?
I return often to this quote, to the point of boring people that know me well.
I have spent quite a bit of time over the last few months working with some very exciting start ups. I’ve taken what I’ve learnt while at SuccessFactors and Gartner, and we apply it, cautiously, to the challenges of fast growing start ups and scale ups. In many cases, there are things that are hard in a start up that are easy in a big company, and the other way around. I probably learn as much from them as they do from me.
Across tech companies, big and small, product management is becoming more of a discipline. The tools to track and prioritize customer requests, ideas on so on are making product management more robust, and methodologies to better align engineering and product are advancing too. It is an exciting time to be in product.
A several start ups have asked me what should we prioritize? I try and shift the conversation to “how to” prioritize, as I think they know their products and markets better than I do, but when they insist, I invariably answer APIs rather than a specific functional thing.
Why?
10 years ago, if you wanted a great reporting user experience, likely you had to roll your own reporting UX layer. Today, that would be madness with what Power BI and Tableau have to offer. 5 years ago if you wanted some sort of messaging, you would have built something in your product, today building for slack and teams is where it’s at. 10 years ago you were building applications to work in one UX, a browser. Today customers demand mobile, short message, chatbot, web, voice and who knows what next. And I’ve not even mentioned where the software runs.
When you have figured out that capability that makes your offering sing, build that thing, but build it in a way that you can take advantage of the galaxy of other good things out there. If your APIS are open, clean, secure and well documented, you will spend less time building things that others have already built. You will innovate rather than duplicate.
And while you will always create some technical debt along the way, good APIs mean that the payment terms down the road are far less severe. Good APIs lower the interest rate, and give you flexible terms.
There will come a time when a component you thought you had to build to achieve your product goal is made obsolete by someone else’s innovation. Rather than cursing that innovation, you should embrace it.
Many of the start up vendors I work with sell to large enterprises. And while selling to the LOB is all the rage, at some point they will need to deal with IT department. If your APIS are top notch, that will remove more barriers to getting past the guard door than almost any nifty additional functionality. Most HR tech involves significant 3rd party integration, so good APIs means you punch above your weight. Shorter sales cycles, better adoption, higher margins, and happy customers.
There are few things worse than dealing with poor data imported into your product when a big enterprise customer is about to go live. Some other vendor’s poor data becomes your problem to fix. A good API will keep the poor data out in the first place, and a great API will provide your with the evidence to prove it, and catch it much earlier in the project. Good APIs will mean your customer success people focus on success, rather than integration “Whodunnit” inquisitions.
By making APIs central to your product design process, you also force product managers to have better technical awareness, and communicate far more accurately. You provide a stable set of constraints for UI designers to work with. It helps make testing integral. It creates a positive discipline. So much goodness.
Make good APIs part of every build, an integral component of your definition of done. You won’t thank me now, but one day, you will wake up and your UX will be old, and you will need to change it. Or the data migration from the 30 year old customer legacy system will run flawlessly and the CIO will send YOU tickets to the opera or the IPL final.
If your company is going to be acquired at some point, a track record of robust APIs will probably do more for your post merger integration earn out and your sanity than anything else I can think of.
