The following is adapted from Build What Matters.
The Never-Ending Customer Commitment Cycle
I vividly remember joining Opower as the VP of product in early 2010. In my second week, the board requested to see a product roadmap. Scrambling to deliver, the obvious starting point was learning from the team what had already been planned.
In doing so, I discovered two surprising facts:
- There was no roadmap, and
- The company had already contractually committed nearly all of the engineering capacity for the next six months to building a hodgepodge of one-off features for newly-closed accounts.
These weren’t the priorities I wanted, and in fact, no one else in the company wanted them prioritized either, but in an effort to close business, they had acquiesced. I needed to communicate to the board and our employees not only what our priorities were but why, so I created a roadmap document that showed all of the features we were required to build over the next six months color-coded in yellow and all the more meaningful improvements we were excited to deliver afterward color-coded in blue. That way everyone saw the reality but also had a glimmer of hope: after headsdown work for six months, we would be in a position to really innovate.
Sadly, that’s not what happened.
Six months later, we had indeed delivered against the client commitments, but the color-coded roadmap still looked exactly the same. In that time, we had continued to make new client commitments, deferring our intended priorities another six months. This would have continued into perpetuity if we hadn’t solved the underlying problem. We were a feature factory! With some great cross-functional teamwork, we were finally able to break away from this pattern.
How We Broke The Cycle
Every B2B SaaS company dreams of being able to build a product, make it available to customers, and have them buy it and get value from it without having to do any customization or product additions to close new business. With excellent product management and salesmanship, that is achievable within most industries. When selling to regulated utilities, on the other hand, it is not. No matter how robust the product capabilities, there will always be some idiosyncratic customer need that has to be accommodated. To have a hard and fast rule of saying no to all feature requests would have cost Opower almost every single deal we won. In effect, we were selling a square peg to fit a differently shaped round hole each time, and the peg had to be modified slightly, or it just wouldn’t fit. That burden fell on product development.
The difficulty was in making the right decisions about when to say yes to a feature request because it was a modification that was needed and when to say no because the deal could still be won without it. Enterprises are notorious for putting “the kitchen sink” into their RFPs in hopes of getting vendors to solve a slew of problems outside of the original scope. If I had been an Opower salesperson, I would have pushed for us to say yes to every single request in the RFP to maximize the chances of winning a deal, and that’s exactly what the salespeople at Opower did.
Of course, in my role running product management, I wanted to say no to every feature request because saying yes meant further pushing out roadmap priorities. It was a stalemate, and while everyone appreciated that we were on the same team, it created an antagonistic relationship and a zero-sum game between sales and product. Something had to be done.
Dan Yates, co-founder and CEO of Opower, called the VP of Sales and me into his office to work it out. We asked ourselves the question, “Forgetting about the specific feature requests and roadmap priorities on the table today, what percentage of our development capacity is appropriate for saying yes to win deals and what percentage should be reserved for true product development?” It was a simple question, and to my amazement, all three of us agreed immediately: given the realities of the market we were selling into, about 15 to 20 percent should be earmarked for client commitments and the other 80 to 85 percent should be reserved for the roadmap. All we needed to do then was come up with a process for prioritizing the right work while holding ourselves accountable for matching the top-down allocation we had just set.
And so the tokens system was born. As long as sales could operate within their capacity allocation, I didn’t feel strongly about what we actually prioritized as long as it resulted in us hitting our sales targets. Sales was in the best position to determine which items were worth committing to and which could be ignored. It worked much like a paid time off plan in which for every few weeks an employee works, they earn days that they can take for vacation. As long as you remain within your earned vacation time, the company has little say in when or where you go. In the tokens system, for every 85 developer-days of product roadmap work, we would add 15 developer-days of capacity, or “tokens,” to a budget that sales could use as they deemed necessary. (I did have veto rights for requests that would result in scalability issues or overwhelming product complexity, but I rarely had to use that power.)
This process was controversial particularly within the engineering team, who felt product management should never defer to other teams. It was controversial enough, in fact, that it has become a classic case study taught at Harvard Business School. Regardless of how people felt about it, the results spoke for themselves:
- A junior salesperson working on a small deal couldn’t come to the product team directly, banging their fist on the table about a pile of feature requests. They had to instead go to the VP of Sales, who would shrug the request off immediately, noting that unless the deal size were larger, it wouldn’t be worth using up their limited tokens. Eighty percent of the one-off requests that used to come to product management vanished overnight.
- When the estimate for a truly important feature request came back higher than the salesperson expected, rather than try to force it anyway, they asked us whether we could work with them (and when possible, the client) on an 80/20 solution that would solve the utility’s need but at a fraction of the token expense. This is exactly the kind of constructive discussion we had always wanted.
- If several different clients were asking for additional product features that were roughly the same, sales leadership would ask whether they needed to spend tokens multiple times. I would respond by explaining that they didn’t need to spend them at all. Enhancing the product to satisfy the evolving needs of the market is exactly what we intended to do with the remaining 85 percent of the roadmap anyway. This was precisely the type of market insight we were looking for from our client-facing teams.
