Richard Shum

Ideas can come from many places. They include customer feedback calls, customer troubleshooting sessions, customer submitted ideas (at Splunk, we have an idea submission portal called ideas.splunk.com), conferences (at Splunk, we host .conf where we have the opportunity to meet many customers in person), ideas from your engineering team (they generate some of the best ideas), and ideas you dream up yourself. Once there’s a list of ideas, we typically do a full re-prioritization at annual planning. Throughout the year, we also slot in new ideas and do minor re-prioritization as things change. 

When I prioritize or stack rank a list of items, I typically find it helpful to understand how each item can (a) deliver customer impact and (b) increase engineering happiness. Additionally, I also find it helpful to understand each item's level of (c) feasibility, (d) urgency and (e) effort. I weigh customer impact and engineering happiness at 50:50 -- after all, you need to make your customers happy while also keeping your team excited. Things that are less feasible are often pulled down the list. Whereas things that are higher urgency or less effort might be pulled up the list. At the end of the day, prioritization is an art.

Before jumping into the "must do" work, it's best to understand the reason for doing the work. Sometimes the "must do" work is warranted. For example, compliance could have high customer impact which naturally means that it'll get prioritized anyways. Sometimes the "must do" work is not impactful. For example, there might be a set of maintenance tasks that is necessary but it's highly manual and repetitive. While it needs to be done, it's more exciting for the team to reduce/eliminate this work through automation than continue doing it over and over again. At the end of the day, there will always be some level of "must do" work. The key is to reduce the unimpactful/repetitive tasks. Once those things are eliminated, the team is often happy to take the more impactful (even if mildly annoying) "must do" work.

It's always good to review roadmaps with leadership on an ongoing basis. These touchpoints allow you to keep your leadership informed and give you the opportunity to solicit feedback. At the end of the day, gaining alignment is key to getting funding and resources. The leadership team is often looking to understand how your product is doing (e.g., usage, adoption, success stories) and how your roadmap can deliver additional impact (e.g., growth in usage, adoption, customer happiness). Clearly communicating how the roadmap can deliver outcomes will help you get buy-in. While unlikely, your leadership can use their power to overrule and change your roadmap. When this happens, kindly ask your leadership to help you understand why they are asking for the change. If the rationale isn't sound, it's ok to push back. If the rationale makes sense, use their line of thinking to help your team understand why the roadmap has changed.

In my mind, several groups of stakeholders often influence the roadmap. They include your customers (both internal and external), your product team (e.g., engineering, design, data science), your internal non-product stakeholders (e.g., legal, compliance, sales) and your leadership. From these stakeholders, it's important to put most of your focus on the ideas coming from your customers and ideas generated by your team. While we all like to work on things that benefit the customer, it is equally important to make sure that your engineering team has the opportunity to work on technically challenging projects even if these things don't always directly benefit the customer. Then, there are times when your leadership would trump everything. Believe it or not, this doesn’t happen often. 

Who to focus on often depends on the maturity of the product. At the beginning stages of the product, we focus heavily on prospective users. When the product is mature, we focus heavily on existing customers (the thinking is -- if you can deliver impact to existing customers then prospective customers will likely find the same features useful). Additionally, who to focus on can depend on whether your company is driving to satisfy existing customers vs working to attract new customers. 

Say exactly that "We're pivoting our product. There are a lot of unknowns and it's difficult to plan too far out." It's perfectly fine to communicate honestly. If there's a good reason for the pivot, no one will fault you for it. If you're able to have direct conversations with customers, it's important that you set up these conversations. Having open and honest conversations is important to build trust despite the pivot. It is also an opportunity to solicit feedback and listen to your customers. Resetting expectations internally within your company will be much easier if you have already held conversations with customers. You can leverage these conversations to prove that the new direction has been validated by your customers. In any case, pivoting a feature or a product can be stressful. But it's also fun.