Ron Hirson


When should you kill a product, how do you treat customers who want a custom feature, and who should have the upper hand between product and engineering?

Ron Hirson   Head of Product, DocuSign / Community Leader   Circle Member

Ron Hirson Head of Product, DocuSign / Community Leader  Circle Member

These were some of the topics discussed at our recent Product | Circle dinner, where 14 Heads of Product at #breakawaygrowth companies gathered for a family-style meal and a conversation about what does and doesn’t work when establishing priorities and making decisions.

Afterwards, we talked to Ron Hirson, Head of Product at DocuSign, about the dinner conversation and what he thought of some of the issues raised.

Here is an edited transcript, below.


FC: What are the dynamics of a health relationship between the Head of Product and the CEO?

Ron: Everyone at the event shared that the most important element of a healthy relationship is trust. In a lot of ways, your job is to translate customers’ needs into requirements. You're translating founders and CEO’s visions into execution.

The dynamic has to be worked out. Trust, translation, and execution are really important.

Having true relationships, even outside of work, is important. I had never met Scott Faber before I started working at Ingenio. Over time, he became one of my best friends. That didn’t happen because I shipped a lot of product; it happened because we built a real relationship.

How do you balance the tension between engineering and product? Who ultimately calls the shots?

It's important to create an organizational structure that at least pretends to have a balance. The Head of Engineering and the Head of Product should both report to the CEO. A structure in which one reports to the other is destined for failure.

Product people often want what is not obviously possible, and engineers, from experience, often have a perspective that things are generally difficult. If engineers are the pessimists, and product people are the optimists, combining the two creates a realist. But this balance can change over time.

In many early-stage startups, the person writing the code might also be the one running the product, while somebody else is out fundraising. If you are actually selling to  customers, a pure-engineering organization doesn't scale. Product management adds a balance and should be empowered to make the tie-breaking decisions.

At DocuSign, product has the road map, the prioritization process, and we collaborate with engineering to make sure that we're realistic about what we can ship. We collaborate on how and what we're going to ship, but the ultimate responsibility lies with product management. If something ships and isn’t what a customer wanted, product is responsible. If something doesn’t ship, product should still be held accountable.

From a product standpoint, how do you balance the need to do the fix cycle with wanting to come up with new stuff?

This investment in innovation vs. core is a debate at every company I've ever been a part of. At a high level, the CEO or Head of Product has to say, "What's important to us as an executive team is that we have X percentage in innovation and Y percentage of investment in core."  What Charles O’Reilly calls the Ambidextrous Organization.

That manifests itself in lots of ways. At DocuSign, we’ve rebuilt our entire signing process, which is the core experience several times. We've rebuilt our administration experience. We've rebuilt our sending experience. You can consider some of that core, but some of it is building new functionality.

On the innovation front, our lab team does incredible things. We also hold hackathons twice a year that encourage folks to think out of the box. Maybe an eighth of the resulting ideas ship, at most, into the product. Others get teams to think about new code bases, new offerings, and new means of delivery.

How do you handle a request for a new or custom feature?

It's an inevitability for every business, but different Heads of Product handle it differently. One might say, "If a customer asks for a feature, we entertain, at the very least, what that feature means.” Another might take the opposite approach, saying, "We tell that customer they're fired. We don't do development that's specific for a customer, ever.”

Those two poles are not going to actually meet, but I think they're moving more toward each other.

At DocuSign, we have a huge number of customers, and some of them want custom things. We do our best to ensure that we do only the things that affect a lot of customers, drive a lot of revenue, or are strategically aligned with what we want to do.

One Head of Product at the dinner said that when customers request a new feature, he asks them to describe their problem. Is this a common approach?

Yes, I did it today. Salespeople will come back after talking to a customer and say, "Look, we really need this feature." I’ll ask them, "Let’s ask that customer, 'What problem are you trying to solve?'” We might have a better solution.

Another topic of discussion was whether it's smart to share road maps with your sales team and customers. What's your strategy?

If you don't actually have a shared vision, the people inside your company don't know what they're working toward. They just grind out features.

Knowing what your story is—knowing what’s your vision and mission—helps you align everybody. Then you say to your team and customers, "Here’s what we're going to try to deliver next quarter, and then I'll tell you more generally what we're aiming to do in the next year.”

But if you share your entire road map for a year, sales will start selling something that might be coming four quarters out. If, three quarters out, something shifts in the market that makes you rethink your plans, you don’t want to be stuck following through on a commitment sales has made and thus miss a big opportunity.

That's why you don't want to share a road map with your sales team, but they really want you to share it, so it's a constant struggle.

Do you have a process for determining whether to kill a product?

It's not my strong suit, because I actually haven't done enough killing of products, But it's a simple calculation.

Once you get to scale, you have to figure out how many resources it takes to support the product. The questions are, what revenue does it generate? Having it sit idle—what does that do to your business? Does operations have to support it? Do you have to QA it every time you do a release? Where is it in its life cycle?

Then you make a decision based on the opportunity cost of redeploying those resources to work on something else. Even just saying, "Hey, well, we're not going to develop it, we're not going to put any effort on it, we're just going to let it live" takes resources.

Because we've acquired many companies, we have gone through an exercise of rationalizing our products. We will be turning off several products that will actually turn off revenue from some customers. It's a part of growing up as a business.

You're transparent about that?

Absolutely. Some companies decided to kill support for some products and have said to customers, "We're turning off our API access, and you have 24 hours to respond.” DocuSign is doing the opposite. It's going to take us a year to unwind these things.

We might even find a partner to take over the code base and support those clients, so they don't lose the functionality we no longer maintain. We’re rationally winnowing down what we can focus on.

When Steve Jobs returned to Apple, he killed more than 70% of the products both hardware and software.

It's not easy, but those are the ways I think about killing products. We are in the process of killing, I would say, eight products at DocuSign out of 25. That’s not 70%, but it is a meaningful amount of products.