I’m sure you’ve all heard saying derived from Voltaire, “don’t let perfect be the enemy of the good” which in a way is encapsulated in the lean startup movement and the ideology of shipping a “minimum viable product” (MVP) and then learning from your customer base.

Or to borrow a simple life lesson from Gretchen Rubin,

“The 20-minute walk I take is better than the 3-mile run I never start.

Having people over for take-out is better than never having people to an elegant dinner party.”

I think about this topic of perfection being the enemy of the good often. Because I live in startup land where everybody is a perfectionist. I think this is particularly true because every startup entrepreneur is trying to catch lightning in a bottle.

I hear about it in every first product release. You can see it in the founders’ eyes. They want the perfect feature set, the PR company lined up to do the perfect press release, they want maximum coverage, rave reviews, viral adoption and they want to sit back and then wait for the signups to come roaring in.

Life doesn’t work like that. And gearing yourself up for a lighting-in-a-bottle moment leads to bad company decisions.

Even in the age of MVP worship I see founders who want to bundle too many features into a release because they’re worried that customers will be unhappy if they don’t.

I see teams holding back on product releases even when the product is complete because they’re nervous it’s not yet good enough to get positive journalist reviews.

They hold back on announcing their funding because they want to be sure they have 3 other important announcements to bundle – I often counsel against this.

Stop trying to catch lighting in a bottle.

Your announcement will lead to more traffic than you’ve had in the past. But it’s highly unlikely to have that aha moment that Apple gets when it announces new products.

The much more likely result is that you get some positive feedback from the community, you get some strong users who like your product, you get some people telling you your product isn’t as good as the competitors or isn’t as good as your marketing hype.

That’s ok.

Launch and learn.

JFDI.

No battle plan ever survives contact with the enemy. So the sooner you’re live the sooner you’ll be able to separate your own internal BS from what the market really wants and thinks.

The other reason I counsel so much on this topic is confidence.

You gear your who team up for your TC Disrupt presentation, your interview with Kara Swisher, your graduation day from YC and waiting for the product success.

And when it doesn’t come in droves it feels like defeat. And the whole company feels it because you set expectations too high.

The golden rule of management is to set low expectations and beat them. Lightning in a bottle breaks the cardinal rule.

So be prepared for the marathon. Expects a long, slow linear climb.

Take some comfort in Fred Wilson’s blog post about MeetUp and the 20-year-build.

After all – some people win the lottery. And that’s who you read about in the papers. And it feels nice to think that $285 million is just one Lotto ticket away.

But you’re a pragmatist. And you know that your success will come from the hard work and refinement of 20 different product releases each that incrementally made you the great company that you are.

And by being in the game long enough – if you’re lucky, smart & tenacious – you might just see that traffic & revenue arc up.

p.s. no – I’m not talking about your specific company. I know I gave you this advice so you think I’m picking on you. I give this advice to every young startup. Promise.

This is my third post in a series on Enterprise Software.

In part one I covered the need for early-stage enterprise software companies to build up professional services staff to ensure successful implementation projects. This goes against the conventional wisdom of VCs.

In part two I talked about how to ensure that your professional services practice doesn’t take over your software company although I’m on record that there is nothing wrong with a services company as long as you’re not VC backed.

This post is about how to work with your largest customers when you’re an early-stage software company and about how you can increase your margins by selling your roadmap.

For starters as a young enterprise software company you need to think about the customer segments you serve. One way of slicing customer segments is by size. I have a metaphor for this that I use with startups called “Elephant, Deer & Rabbits” in which I encourage most startups to be deer hunters.

The analogy is that Elephants are a lot of meat but overwhelm your company. You end out bending too many of your R&D (and other) resources to serve them and you end up acting like an internal R&D department. And even then you’ll struggle to serve them properly.

Rabbits are plentiful. You see them everywhere so you confuse them being easy to catch but when you try to grab a bunch quickly (they look so close!) they run fast and even if you did catch them you wouldn’t get much meat.

That’s why I like deer. Easy to catch. Lots of meat. And right-sized to serve as a customer base since they might need you as much as you need them. They’re not overwhelming.

When you do manage to land a few larger customers (elephants) you need to provide high-quality service, which is one of the reasons in my first post I outline the need for an in-house professional services organization.

At my first startup we realized we couldn’t handle too many high maintenance ones so we had to be selective in whom we would serve. We also realized that they were going to consume a lot of resources and have a lot of requests to customize our product so we had to be careful which features we would commit to them.

I learned early on that what some of the larger clients wanted was to feel like they could have influence over our organization. They were seeking an asymmetric relationship in which they would be important enough to us to get what they wanted out of us in a way that they couldn’t get if they worked with, say, SAP.

So we tried to use this to our advantage.

We created a “platinum customer” insider list in which we granted very few customers access. This group was given access to our R&D wiki so they could monitor what we were producing and what we were planning.

We held semi-annual platinum customer retreats in which they got to participate in all-day planning seminars with our product team and technical leads. I would personally attend the summary sessions to hear directly what their major requests were.

In many ways this was a benefit to us because our teams got direct insight into how our largest customers were using our products and more importantly what our currently solutions couldn’t solve for them. We were able to build deeper relationships with our largest customers through this process – mostly with the people responsible for the implementation success.

Importantly we were also able to use the “platinum customer club” as a sales tool as we were trying to land larger accounts. For buyers who want a more hands-on approach some of the key buyer values are access and leverage. I can tell you from experience that they also value the networking that they get with their peer groups and we marketed this heavily.

As we were deep in the sales process with the larger accounts we would offer them access to the platinum club as a way to hold the line on price negotiations. Conversely if we needed to give in on our price negotiations to win a deal that centered too much on price we were able to say we would drop their access to the platinum club but give them a better deal on price. Value-based buyers preferred this.

I know most technical & product people hate the idea of having to haggle with customers but it’s a fact of life on enterprise accounts as I talked about in my post “Everybody Wants Their Pound of Flesh.” In fact, if you’re somebody that feels uncomfortable with negotiations I’ve written a series on negotiation topics here.

So about the “selling the roadmap” bit …

When working with our platinum customers we let them have insights into our planned roadmap and also let them have their vote on what was important to them. We did our best to meet as many customer requirements as we could while also making sure that it didn’t take over our entire development effort.

If your largest customers dictate your entire roadmap then you’ll never do anything strategic – you become their R&D department. That’s a real risk so you have to manage expectations carefully.

When we published our roadmap to our platinum customers we would inevitably get some complaints that some features were coming too many quarters out and they preferred them done sooner.

There was an easy solution to meet their requirements and our own. We would allow them to accelerate some Q3/Q4 initiatives to Q1/Q2 if they would fund the development. Often 2-3 customers would band together to fund an accelerated plan.

Before you think it, this was not prostitution. These were always features we knew we needed to build anyways – we were just willing to accelerate / prioritize them.

We would staff projects accordingly either by hiring an extra engineer early (one we had planned later in the year) or by using contractors to supplement some non-core coding.

It was a win for all parties. We got accelerated development of high-priority projects and we got needed, high-margin revenue by selling our roadmap.

Our customers got access, a network, influence and an accelerated timetable to get features that would help their business earlier than we could have developed them without the additional cashflow.

Win all around.

I know this is a sensitive topic, one that some will wince at. The idea of selling your roadmap.

But on your journey to building a successful enterprise startup don’t imagine that every other successful enterprise startup is Howard Roark pure. I worked inside one of the largest and most successful enterprise startups in the world and I can tell you that nearly an entire release of our code was dedicated to one major financial services customers.

Only the scrappy survive.

Photo is The Egyptian Bazaar by mehmet avincan – Downloaded from 500px (licensed for my personal use)

Oh yeah? But I still don’t get it? What’s with that image of an Egyptian Bazaar?

Well, I was going for the analogy of “my friend, have I got a deal for you” that you get at a bazaar in Egypt or a stall in Mexico. I didn’t quite find the image of the loud salesperson begging for the deal / haggling with you (selling his soul for any deal) but I found this visually stunning photo so I just went for it. I know. I’ll try harder next time

This article originally appeared on TechCrunch.

I recently wrote a blog post in which I pointed out that many investors & advisors discourage enterprise startups from having a professional services (PS) business and I think this is a big mistake.

I think it’s important for enterprise startups to layer in professional services into your revenue stream.

PS capabilities are important for enterprise startups because they:

• ensure your projects are more successful & thus more referenceable
• help you integrate your product with other systems making it harder for your product to be replaced by competitors
• make sure you do higher quality implementations because 3rd parties don’t have the same interests in over delivering on quality
• provide you with best eyes & ears on the ground at clients to drive upsell, cross sell & rollout across more business units
• deliver profitable revenue that while on gross margins of 50% vs. software at 85-95% it is still profits to help you cover fixed costs

[it's all in this article if you want the details]

BUT!

You don’t want to run the risk that having a PS business that takes your eye of off the ball of growing a large software business.

So when I meet with GRP portfolio companies that do enterprise sales I try to emphasize the following:

1. Only Work on Projects That Support Your Core Product Effort
The most important thing to be careful about is to be sure WHY you’re doing the PS business. Hopefully it’s not as a way of avoiding fund raising or finding quick pockets of money.

Don’t become addicted to the quick hit of cash that a big implementation project can provide.

Your goal should be to do PS as a way of accelerating future non-linear software growth.

Therefore you need to be careful not to accept projects that are too far out of the core business. Each project should be related to rolling out your solution (or you shouldn’t do it). Each project scope should be as close as possible to being restricted to:

• software set up
• training
• rollout support
• integration with other systems
• configuration

That is the software business.

In the Ad Tech world PS revenue often means providing “media services” as a value-add to using your product. This might mean helping customers buy traffic, arb’ing deals, helping with RTB pricing or trading, etc.

2. Minimize Any Custom Work That Will Not Feed Back Into Your R&D
While I’d like to say that you should never do custom work that changes the scope of your product that’s not wholly realistic.  But you do need to be sure your company doesn’t just become the internal R&D department for a large corporation.

If you never read my post on Elephant, Deer & Rabbits – a guide to customer segmentation – it might be worth a read.

With a well architected product that has well-documented APIs and proper core product abstractions then all custom work should be build above the API stack. Often your sales engineers can do the customizations without bugging the core eng team.

Extending the feature set of the product  would obviously be better if done by the customer but sometimes customers lack the resources to do customizations so simply telling them to get stuffed is not the answer.

3. Protect Your Intellectual Property
If you’re doing custom work restrict it to a small portion of the PS project and that you try to build stuff that can eventually find its way back into your core product roadmap improving your core offering for future clients.

In fact, if you do the PS project well and narrow the scope to features that you know you’ll eventually need to build anyways then it can actually be a great source of future innovation.

Importantly, make sure that you retain IP rights to your custom work which needs to be part of the engagement contract. At a minimum co-ownership of the IP.

If not specified in contract you might find yourself with future litigation over IP.

4. Integrate PS Work Into Sales & Marketing Processes
The reason to do the PS work in the first place is to drive future software sales. So make sure that your PS organization doesn’t become an island or a P&L unit who tries to maximize its own value by showing the most profitability and growth on that business unit possible.

The PS team is there to deliver a successful engagement. You want to make sure that they are communicating well & often with sales to drive future product sales at the customer.

You want to be sure that you get customer commitments before doing the work do agree a case study afterwards if the project is successful. You won’t get every customer to agree this but you certainly want to try with every customer. Referenceability is the lifeblood of sales. If asked to drop price we would often counter by agreeing to small price decreases in exchange for an agreement to do case studies to drive future business. Frankly, you’re going to need to drop price a bit anyways. After all, every customer wants their pound of flesh.

If you have a sales rep pushing a product implementation you want them to understand why selling PS will help them grow future revenue at that account not as a crutch to hit short-term revenue targets.

Basically, no islands at startups. Everything needs to be part of a holistic company strategy.

5. PS Business Cannot Become a Management Distraction
Another rule I outline with our portfolio companies who sell enterprise solutions is that I don’t want them to become a distraction for management.

If your CEO is having to get involved too much in reviewing project success or your core product team is getting sucked into implementing too many features to support the rollout efforts chances are you’ve gone too far.

The closest analogy I have for a PS person is a “sales engineer” who is normally a technical staff member who assists in sales campaigns. Often they have the same skills and can therefore be doubled up as PS if you are in a pinch to afford staff.

If PS involves too much management or core tech time then chances are it will overtake your software strategy and you’ve then just become a prostitute for short-term revenue.

6. Control Size of PS Revenue Relative to Software Business
So how much PS is too much?

There’s no right answer. It’s mostly a function of the stage of your business.

If you’re in your first year of developing your product chances are you haven’t yet found product / market fit and you don’t yet have enough value to sell your product for as much as you’d like.

And chances are you’re in big need of a killer customer reference.

So it wouldn’t bother me if 90% of your year-one revenue was PS provided it was done with a specific plan for year-2 software sales. It also is a great way to finance your business without facing dilution before you actually raise venture capital and when the valuation you might get from angels is less than you’d want.

By year 2 I’d like to see PS at 50% maximum, which is still high.

By the time you’re at $5-20m in software sales I’d like to see PS be no more than 25% of your total revenues.

I know that number sounds high for some people but in reality if you’re growing fast it’s not unthinkable that you’d bill out $2.5m in PS revenue on top of $7.5m of recurring revenue (MRR) software sales.

As you hit steady state I’d like to see PS as about 15% of your business.

Rough guidelines. Lots of room for debate. But a good rule of thumb for planning.

7. Don’t Pay Full Bonus to Sales Staff on PS Revenue
Finally, be careful that you don’t incentivize your sales staff to make you into a professional services firm. You can’t pay full bonus on PS revenue. Not only because it’s lower gross margin, less scalable and more consumptive of staff but also because if you make it easy for them to sell PS which is always higher revenue than paying for software you’ll be sure they sell it ALL DAY LONG.

But it can’t be zero bonus.

If you have zero bonus on PS revenue you’ll find a sales team that becomes the PS prevention unit and if you’ve bought in that this line-of-business is important to you then you don’t want your best sales teams working against you.

There’s not one answer for how to comp the sales teams. Can be margin based. Or lower spiff for PS revenue than software revenue. Whatever. And obviously you need to persuade them that today’s PS business is tomorrow’s big commission check.

Happy to take any suggestion in the comments section as to how to properly incentivize sales teams.

Next post?

“How to sell your future roadmap to enterprise customers without selling your soul. Adding precious high gross margin to support an R&D team that you need to fund anyways.”

Photo credit Food52.