Clicky

MANAGING THE BUSINESS OF SOFTWARE

Can you develop faster than you sell?

Subaru Wrx corre mersan

Here’s something I’ve been thinking about: What if you could develop faster than you sell? What if you could have a product release (or two) during the sales cycle?

A buyer wants a feature that’s planned for later in the roadmap. Since it’s crucial to a deal, we can put it into the queue for the next iteration and have the feature online in two weeks, long before the contract closes.

Your competitor announces a new feature. If you have a top-performing product team—and if it makes sense for your roadmap—you could develop and deliver the feature while your competitor is still showing prototypes.

You’ll want to avoid the appearance of being a custom developer but the promise of agile teams is they can react to changing requirements quickly. (However, they react badly to continuous change.) Use the "development pull" technique to align changing market conditions with consistent product team deliverables.

A release is the end of development and a launch is the beginning of promotion. It may help to revise your thinking: a release is the end of development and a launch is the beginning of promotion. [Tweet this]

I tend to work with enterprise companies with multi-month sales cycles. Most of the product teams I’m working with have adopted agile techniques—particularly scrum and kanban—while the rest of their organizations are still working in a more waterfall fashion. They haven’t really integrated rapid development into their company rhythms.

I worked with a company that had a LONG development cycle, typically 18- to 24-months between releases. The sales cycle was long too, usually 6 to 9 months. One of the reasons we were so slow to deliver was that sales people (with executive support) included custom work in some contracts to close the deal. Which delayed the next release again and again.

I put a stop to that by going to quarterly releases. We prioritized the backlog based on business value and customer importance, and I queued work to development based on the current top priorities. That is, development pulled work from me when they had capacity and I was always able to give them the most important thing—either something from the roadmap or a critical bug or a special for customers. With a quarterly cycle, development got into a consistent release rhythm and we could move stuff around if needed for a critical sale since our release cycle was shorter than the sales cycle. We’d likely see one or two releases in the typical 6- to 9-month sales cycle.

This idea doesn’t make sense for consumer products that people purchase on a whim in 90 seconds but it makes lots of sense for complex B2B products.

What if you could develop faster than you sell? How would that impact your product teams? How would a nimble product team strengthen your sales approach? Add your comments below.

Release and launch planning is a key part of your product playbook—a collection of workshops, tools, and templates to ensure your team is systematic in their methods and consistent in their deliverables.

 

Return to Blog

Can you develop faster than you sell?

Subaru Wrx corre mersan

Here’s something I’ve been thinking about: What if you could develop faster than you sell? What if you could have a product release (or two) during the sales cycle?

A buyer wants a feature that’s planned for later in the roadmap. Since it’s crucial to a deal, we can put it into the queue for the next iteration and have the feature online in two weeks, long before the contract closes.

Your competitor announces a new feature. If you have a top-performing product team—and if it makes sense for your roadmap—you could develop and deliver the feature while your competitor is still showing prototypes.

You’ll want to avoid the appearance of being a custom developer but the promise of agile teams is they can react to changing requirements quickly. (However, they react badly to continuous change.) Use the "development pull" technique to align changing market conditions with consistent product team deliverables.

A release is the end of development and a launch is the beginning of promotion. It may help to revise your thinking: a release is the end of development and a launch is the beginning of promotion. [Tweet this]

I tend to work with enterprise companies with multi-month sales cycles. Most of the product teams I’m working with have adopted agile techniques—particularly scrum and kanban—while the rest of their organizations are still working in a more waterfall fashion. They haven’t really integrated rapid development into their company rhythms.

I worked with a company that had a LONG development cycle, typically 18- to 24-months between releases. The sales cycle was long too, usually 6 to 9 months. One of the reasons we were so slow to deliver was that sales people (with executive support) included custom work in some contracts to close the deal. Which delayed the next release again and again.

I put a stop to that by going to quarterly releases. We prioritized the backlog based on business value and customer importance, and I queued work to development based on the current top priorities. That is, development pulled work from me when they had capacity and I was always able to give them the most important thing—either something from the roadmap or a critical bug or a special for customers. With a quarterly cycle, development got into a consistent release rhythm and we could move stuff around if needed for a critical sale since our release cycle was shorter than the sales cycle. We’d likely see one or two releases in the typical 6- to 9-month sales cycle.

This idea doesn’t make sense for consumer products that people purchase on a whim in 90 seconds but it makes lots of sense for complex B2B products.

What if you could develop faster than you sell? How would that impact your product teams? How would a nimble product team strengthen your sales approach? Add your comments below.

Release and launch planning is a key part of your product playbook—a collection of workshops, tools, and templates to ensure your team is systematic in their methods and consistent in their deliverables.