How not to work with HRTECH start-ups. The enterprise edition.
"Be cautious about generalizing, especially if it leads you to the conclusion that other people are idiots."— Economics in Bricks (@econinbricks) December 25, 2019
– Hans Rosling pic.twitter.com/4uGCLqk8vv
Thanks to @econinbrinks. An excellent source of wisdom.
When I was at Gartner I helped enterprises grapple with enterprise vendor contracts. I know several specialist advisors that do an excellent job of helping enterprise corporates blunt the negotiating power of the mega-vendors. But I would like to look this from a different angle today.
Since starting my advisory business, I’ve spent a lot of time advising and coaching HR Tech start-ups. It is a lot of fun, and often I get to learn from them as much as they get to learn from me. I bring my experience of scaling products, and of how corporates buy and use HR technology. I get to see how fresh minds address old and new challenges. For start-ups and scale-ups, working with large corporates can be very challenging, and helping them navigate the pitfalls and challenges of the large corporates is an important part of my work.
I’ve seen how some large corporates work well with start-ups, and I have seen others that don’t. I’d like to use this week’s column to give some examples of how corporates stifle start-up success. Some of these behaviours are easily avoidable, some require a good look in the mirror.
10 things you need to stop doing now!
Treating HR start-ups like you treat large vendors:
Large vendors can cope with long sales cycles and multiple buying centres. Experienced account managers structure account plans, and they have armies of lawyers to argue with your lawyers. They typically understand how to navigate your procurement processes and your politics. The political dance between you and the large vendors is complex, and sales cycles often last 9 months or more. While 9 month sales cycle may make sense when you are spending 10s of million euros a year, that level of introspection and bureaucracy is simply wasteful when you are spending say 150k a year with a start-up.
Bringing your data protection officer into the project late:
Last week I spoke with a start-up who had been working with corporate for over 9 months on a deal for 200k per annum. At the last minute corporate data protection officer heard about the project and put it on hold. As the solution processes personal data, it was right that he was involved. The solution actually met the datenschutz requirements, but it took the corporate another 4 months to sign the deal. If the corporate had involved the datenschutz officer earlier in the process, there would have been no delay. Involve the DP and Work councils early in the project.
Starting never-ending pilot projects or worse, large vendor bait:
A pilot project can help both the start-up and the corporate, but often these go on too long. Make the pilot focused and committed, and then make a go/no go decision for a broader roll out. Be clear about your decision criteria for pilot success, and then follow through with the real deal, or kill the pilot. Even more evil, sometimes corporates will pilot or do a proof of concept with a start-up as part of a negotiating game to influence their enterprise vendor roadmap or negotiations. This is nasty, as you engage the start up in a process that you have no real intention of following through on. You may get to do this once or twice, but word will get out.
Forgetting you are buying a SaaS product, not a bespoke project:
Start-ups want to build solutions that delight many users, not just you. A SaaS solution is not a bespoke consulting project. The start up wants to understand your business issues and challenges, and then figure out an innovative solution that helps you and others. They don’t need to be bullied into building what you demand. Just because you are big and powerful, doesn’t mean that you should overpower the roadmap. Learn to accept a ‘No’ from the start-up.
Making out that your internal standards and cycles are industry standards:
SaaS products need to meet industry standards, like ISO27001, SOCII, DPIA, WCAG etc. So you are right to demand these. But you can’t expect standard SaaS software to comply with your own internal on-premise IT standards. And please don’t ask them to put the product in your data centre, unless you are Amazon, Microsoft or Google. Also, by all means do a pen test, but test what is specific to the start-up, not all of AWS, again. Equally, demanding that you determine the release cycle is not wise, as you will be slow to adopt innovations, and you will comprise the start-up’s ability to innovate. Having multiple lines of code is grim for the vendor. Cloud/SaaS is not on-premise. I advise start-ups to walk away from deals that compromise product architecture and innovation
Playing contract politics: Only big words for ordinary things.
SaaS contracts are meant to be the same for all customers, especially for terms such as service level agreements. Do the contract on their paper, not yours. If your requirements are reasonable, the start-up should include those terms in their standard contract. Once you have done your product due-diligence, sign a fair, multi-year contract, with termination for good cause rights, of course. I’m not sure why anything more the 30 days is justifiable today, and playing procurement games about wrong invoice formats, and then delaying payment is petty. It may look good for your Accounts Payable stats, but it will not build partnerships.
Most modern SaaS start-ups have better APIs and integration options than corporate IT departments do. Don’t force antiquated integration frameworks onto the startups, especially in the pilot phase.
A division pretending to be the enterprise:
When divisions of large corporates buy software, it is often the worst of both worlds. They inflict long sales cycles, demand large discounts and premium white glove service, but the actual deal size is not actually enterprise size. Don’t promise an enterprise deal unless you really have the power to deliver one.
Marketing Non-disclosure agreements:
Let the start-up announce the deal, and better still, you announce it too. When you don’t let the start-up mention the deal, you limit their opportunity to land more customers, which is in your interest. And when you go live, then let them make some serious noise. Eat the go live cake, and take lots of pictures. The better reference you become, the better support and roadmap influence you will have.
Occupy advisory board seats without contributing:
Large companies often demand a seat on the product advisory board as part of the deal. The best advisory boards are made up of people that have a genuine interest in the long-term success of the product. If there is someone in your organization full of innovative ideas and energy, then volunteer them for the advisory board, but don’t demand roadmap voting rights just because you are a big customer.
I’m convinced that when enterprises collaborate effectively with start-ups, great things can happen. You will feel a great sense of satisfaction when you see a start-up that you and your organization took an early bet on go on to succeed beyond your wildest expectations. All the great enterprise software companies built their products through learning from great customers.
I published a German version of this post on the Haufe site last week.
I'm a venture capitalist at Acadian Ventures, investing in the future of work.