How does an enterprise software company that by definition has a layer between itself and its customers’ users ensure “customer-driven” releases that are not dictated either by those that can shout the loudest or by the “recency (most recent requests get the most attention) effect”?

This post explores the feature request process that Tasktop uses to handle the growing number of requests from its large and expanding enterprise customer base.

In Part I of this series, we discussed the quarterly cadence that Tasktop follows to align departments across the organization, so it can release successful product versions on a predictable cadence. This revealed that at the highest level, process actually enables our ability to be agile. The focus of Part II is Tasktop’s feature request process, which has increased responsiveness to customer needs.

Tasktop builds software that integrates the various systems an organization might employ during its software development lifecycle.While in my early days, we were a 60-person company, today we are edging over 100. As part of this growth, existing teams expanded, and new teams formed, like our Pre-Sales department, whose purpose is to work with Sales to help enterprise prospects evaluate our products.

Our growth has driven up the number of incoming requests related to our products. To ensure that customers’ highest-value and highest-priority needs are being met, we’ve put into place a request process, template, and timeline that provide us with all of the information needed to properly evaluate requests across the board and plan for future releases at the appropriate time.

Feature Request Process: The Submission Process

In the past, incoming requests could be sent in via a number of channels — an informal Skype message, an email, via a phone call, etc. However, the overhead for the product team to handle these became quite high.

Because of that, today product feature requests from customers and prospects are primarily funneled to the product team via our Pre-Sales or Solutions teams, which are closely connected to customers, and serve as their conduit. We had already used a system to manage our product backlog, so we simply decided that any serious requests should come into the one system by the end-requester. This doesn’t mean that we discourage conversation and informal interactions, but it does mean that we always remind people to send requests in officially so that important requests don’t slip. The bottom line is that in exchange for requesting some formality, the field and other parts of the company obtain good visibility into what is/is not coming, and we can include them in the decision-making process.

Feature Request Process: The Template

As we grew, we realized the importance of having certain pieces of information available to help us evaluate requests, and decided to put into place a feature request template. Though a seemingly simple change, it is one that has been challenging to implement, but incredibly useful to help our team make decisions.

The template includes the following types of information:

• Description of the Customer’s Problem/Need — We stress that requesters describe the problem at hand rather than prescribing a solution to ensure that we fully understand the need before developing a solution. We also ask that the requester detail whether there are any workarounds in place to gauge how much of a blocker this is.
• Customer/Prospect Information — Knowing which customers are interested in a request, and seeing how many different customers inquired, is a good metric to inform our decision-making. When a request comes in, we see if it already exists. If so, we add the new customer information to the old request and mark the new one as a duplicate. If it does not, we keep it and make sure the inaugural customer requester is tagged.
• Potential Deal Size — Is a feature a critical request of a prospective customer in a large deal? This may strongly influence whether the feature is added, although a request doesn’t have to be driven by potential revenue.
• Level of Urgency— Will lack of this feature prevent potential customers from buying? Is it is crucial to maintain a good relationship with an existing customer or partner? Or is this simply a “nice-to-have”? This is perhaps the trickiest piece of metadata, requiring a combination of the salesperson needing to understand the dynamics of a given relationship and of the Pre-Sales engineer to know the technical challenges. Tasktop tracks this information with visibility all the way up to the executive leadership team.

Taken together, this information helps the product team understand customer needs and the relative importance of requests as we work to determine what to do and when to do it.

Feature Request Process: The Timeline

As mentioned in Part I, we take steps to plan the next release as early as Sprint 2 of the current release cycle. Though requests come in continually, we proactively reach out to our stakeholders to prompt them to make submissions, triaging them as they come in across our products (more on this in Part III).

Such requests kick off an iterative release planning process, in which we go from macro level with scenario-based options to a finely honed will/should/could release plan – in the span of about four weeks.

To get a sense for prioritization among requests for a given product, we sometimes host “Buy a Feature” sessions to investigate what people would really choose with limited options. And then, knowing that our teams have limited capacity, we develop various scenarios for each team that would deliver different outcomes. The creation of these scenarios takes a tremendous amount of skill and nuance.

These scenarios then are vetted by our executive leadership team, which weighs the options at a macro level. The result is a proposal that we can take to the development teams to review. The teams discuss features, kick off any business and technical analysis to help explore what those features would be, and get rough SWAGs. This results in each team having a full release plan with an associated set of confidence levels that describe how likely team members think they’ll be able to achieve a certain feature. The product owner and team lead then present this to the company to kick off each new release cycle.

Feature Request Process: Adapting to New Needs

Like your organization, Tasktop receives unexpected requests all the time. It may seem counterintuitive, but this formalized request submission and release planning process accommodates new incomings quite well.

When requests are sent in, individuals can “fast-track” them, meaning that they’d like them to be accomplished in the current cycle, even though it isn’t in the original plan. When a fast-track item arrives, we meet with the requester to understand the need immediately. When technically feasible to do in the time frame needed, we can we make logical tradeoffs because we know what the original driver was for each feature on the plan and how urgent it was deemed.

While it took some time to establish, this new process runs smoothly and provides the organization with the visibility it needs into what we plan to deliver while giving us the flexibility to adjust to unexpected customer needs that arise. And it’s assisted Product in managing all of the incoming requests.

Tips

• Recognize the level of process that you need depending on the size of your organization. When we had fewer than 50 people, this was less important. Fortunately, we anticipated that we would need to formalize our process and got ahead of the curve.
• Understand the information you (or your Product team) need to make decisions, and make sure that obtaining that information is accounted for in your process.
• Once you identify the appropriate level of process and pieces of information you need, underscore its importance to the stakeholders sending in requests. Getting our teams to adhere to our process took some time; we succeeded by making sure people knew why it was important and by reminding them to follow it constantly.
• Don’t let the formal process outweigh the conversation. Though we do ask that individuals submit requests in a certain manner and include specific information, we ensure collaboration by talking directly to our requesters.