DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
  1. DZone
  2. Culture and Methodologies
  3. Agile
  4. Agility Meets Process: How to Ensure Customer-Driven Product Releases (Part 2)

Agility Meets Process: How to Ensure Customer-Driven Product Releases (Part 2)

Continuing on with her series, 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.

Cynthia Mancha user avatar by
Cynthia Mancha
·
Oct. 14, 16 · Analysis
Like (3)
Save
Tweet
Share
3.79K Views

Join the DZone community and get the full member experience.

Join For Free

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.
Release (agency) Requests agile

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • AWS Cloud Migration: Best Practices and Pitfalls to Avoid
  • What Is Policy-as-Code? An Introduction to Open Policy Agent
  • Agile Scrum and the New Way of Work in 2023
  • GitOps: Flux vs Argo CD

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: