product management

When your behavior doesn’t match reality

In order for you to achieve both your short term and your long term business goals, you have to have a deep understanding of who you are as an organization. It’s imperative to have ambitions and to envision what you ultimately want your company to be and to look like, and it’s just as important to understand where you are currently and to act accordingly. Failure to understand the current reality or to have a false sense of self will make it much more challenging to get to where you want to be in the future. Here are a few examples.

Automating too much

If you count on customer service to be a key differentiator, ensure that you are giving your customers the individual attention they deserve. As you are growing your customer base, there might come a time when your team starts to think too much about scaling up, prematurely, and doesn’t focus on the personalized service they should be delivering. If you spend more time on automation than on actual service, reconsider your approach. Don’t automate yourself into indifference, but instead analyze how much personalized outreach and attention you want and should give each customer and find a way to make it happen. 

Delegating too much or too little

As a manager, you may worry about delegation. Are you delegating too much? Too little? Once again, it comes down to critically assessing who and where you are as a company. This is particularly important when it comes to interacting with customers. As a company with several hundred enterprise customers, do you think upper level management should engage with individual customers? I do. But the threshold is, of course, different for each organization. The key is to act according to your reality and not your aspirations. Does your VP of Product need to be involved in certain levels of UX decisions, or would it make sense to empower team members to make the call? If it’s the latter, what do you need to do to make it so?

The “I shouldn’t have to” trap

Another example of potential incongruence between your reality and your thoughts can be found in the “I/We shouldn’t have to trap”. If you catch yourself thinking “I shouldn’t have to tell them to make calls”, “We shouldn’t have to tell them that this issue needs to be resolved immediately”, “I shouldn’t have to remind them how important response times are”, or “We shouldn’t have to postpone the release” (you get the picture), stop for a minute to re-think, because clearly, you have to right now. Instead of an internal eye roll, accept that you are not where you want to be, analyze the reasons for it, and identify the steps necessary to improve the areas that are causing you heartburn.

Misreading your culture 

Your company culture can be one of your biggest, if not your biggest, assets. It’s how people feel after interacting with one of your team members. It’s where the company handbook leaves off and how people act when nobody’s watching. A great culture spawns a sense of pride, and rightfully so. It’s only natural to brush off things that aren’t quite perfect, or to overestimate or underestimate certain parts about your team. Your team may be such an integral part of you that you may be blind to certain shortcomings, but if you are, you don’t empower yourself to help them improve and become even more successful. 

Being realistic about where you are and who you are is a necessary step towards moving towards your goals. Be sure to always take inventory, self-reflect, and make adjustments, not just when the results don’t match your expectations.

What about you? Can you think of situations in which not being brutally honest about your reality could adversely affect your company?

How to obtain useful feedback from your customers

As you are building your product roadmap, you want to ensure that you have as much insight as possible into your customers’ needs. And not just their current needs – you also need to anticipate what types of challenges will be on the horizon for them. After all, customer success is the be all and end all, and that’s why we place so much value on our customers’ input, of which there is no shortage, luckily. The key is to extract the most useful feedback and to act on it. Here are some thoughts on how to do that. 

Provide multiple feedback channels

In order to get useful feedback, you start by getting feedback in the first place. Make it easy for your customers to voice their opinion and to solicit their ideas, and accommodate each individual’s preferences with regard to communication. Some people prefer written communication, others may provide input in passing as they’re interacting with your team, while others might be more than happy to have dedicated feedback sessions with you. For instance, we have an Idea Portal, where customers can submit their feature requests and vote on ideas. In addition, all customer-facing team members, such as Support, Services, Training, and Customer Success, write down feedback that they’ve received and submit it to Productboard, which is where we house and process all input and plan out our roadmap. Furthermore, our Head of Customer Success and I have many, many feedback sessions with our customers throughout the year. Finally, we’ve hosted focus groups during our user conferences. Be sure to identify those customers who are willing to answer follow-up questions, and respect their time and their communication preferences for follow-ups as well. 

Focus on the outcome, not the specific feature 

Henry Ford once famously stated “If I had asked people what they wanted, they would have said faster horses.” Don’t get me wrong – our customers have approached us with many amazing ideas for new features. However, in order to make sure that we get the most useful feedback, we always try to focus on the desired outcome rather than a feature. We want to have a clear understanding of what our customers are looking to accomplish so that we can find the best possible solution for them, and we certainly don’t just want to copy something that a competitor is doing. In order to innovate, always focus on the desired result, not the functionality. 

Ensure diversity of feedback providers

Some customers are easier to get ahold of than others, which is why I’ve seen companies only receive feedback from the same core group of champions – a dangerous mindset! Instead, make every effort possible to solicit input from a broad variety of clients, including those who tend to be quiet. Another pitfall is to only reach out to your main contact at an organization. It’s simply not sufficient, for example, to only talk to a technical user(s) and not the non-technical end users, or to focus on the needs of the IT department when Marketing and Communication departments are the primary users of your product. Connecting with multiple people at each organization takes a lot of effort, but it’s absolutely mandatory if you want to get the most useful feedback in order to deliver the best products.

Crank out those prototypes

Once you’ve decided to move forward with new functionality, continue communicating with your customers (and your internal stakeholders). Since most of them are visual, you can increase your chances of getting actionable and quality feedback if you can show them prototypes. One word of caution: don’t try to perfect the prototype. It doesn’t have to look pretty, and it doesn’t have to include everything that a feature could possibly do. With prototypes, speed is most important. When sharing them with stakeholders, explain what you’re looking to get out of the feedback. In most cases, it likely boils down to “would you use this?”, “what would be the impact of this feature on you and/or your users?”, and perhaps “would you pay for this?”, rather than “Should this button be on the upper left?”. 

Give thanks and credit

In order to obtain a continuous stream of inspired feedback, make sure that your customers know that you not just value their opinion, but that you are putting your money where your mouth is by actually acting on the feedback that you receive. Share with them the impact that they’re having. For instance, when you present your roadmap, mention the number of votes that a certain piece of functionality had received on the Idea Exchange. Give shout-outs to customers who initiated the exploration of a specific feature. Most importantly, thank your customers for their thoughtfulness, their time, and their willingness to collaborate with you in order to help you create the optimal solutions for them. 

While not every idea will should make it into your roadmap, it is vital to collect as much feedback as you can, to ask lots of questions, and to focus on desired outcomes. The better a partner you are to your customers, the easier this process will be.

What about you? How do you get the most useful feedback from your customers?

Product roadmap: 4 things to avoid

Managing an agile product roadmap is no easy task. You have to find the right balance between planning ahead and foreseeing trends and at the same time being flexible enough to adjust your course when new opportunities arise. It requires smart hiring in order to ensure that your team has an agile mindset and good internal and external communication skills. Today, let’s take a few minutes to look at some things that you might want to avoid in your product roadmap.

The ‘demo’ feature

You’ve been there. You want your product to not just be the best on the market for your customers, but you want to wow prospects at first sight. No matter how confident you are in your product, you feel the need to implement a certain feature because it would demo really well. Be careful. Resist the temptation to put something into your product for the wrong reasons. Critically assess the following:

  • Is this feature really going to move the needle for your customers?
  • Are your customers really going to have the resources and processes to use this feature?

A gimmicky feature can have several negative outcomes. For instance, your prospects might immediately catch on and question the soundness of your overall product roadmap. Or they might be excited about it, but once they’ve become a customer, they realize that the feature that “sold them” on your product isn’t really all that useful. Disappointment inevitably sets in. In addition, building a feature solely for the purpose of demos can be somewhat demoralizing for your developers, as they are committed to building the most helpful features, not necessarily the most “salesy” ones.

Build for a particular prospect

The following scenario is especially common in the startup world. You’re hungry for new customers in order to gain traction as quickly as possible. And here they are: a big fish prospect. Getting them onboard would be a game changer. But – there’s a but: The prospect is asking for a new feature. Hopefully, they make the commitment to purchase your system if you accommodate their request. Take a step back. There are very few instances in which this approach is advisable. Yes, there are cases in which the requested feature just makes a lot of sense, but veering from your roadmap in order to make individual customers happy can be treacherous and is not scalable as your product matures and your user base grows. Ask yourself:

  • If and how the requested feature would fit into your overall roadmap
  • What impact would this feature have on other parts of your system?
  • Would this feature benefit the vast majority of your customers?
  • Is the complexity of this feature going to prevent you from working on more impactful ones?

Copying the competition

In one of my previous posts, I talked about the futility of being overly concerned with your competitors. If you’re doing your homework, staying connected with your customers, and staying on top of emerging needs and trends, you shouldn’t have to spend too much time worrying about your competition. That being said, it always hurts to lose a deal to a direct competitor, and if your sales reps tell you that it was because you didn’t have feature X, it’s only natural to reflect whether it wouldn’t make sense to just go ahead and build your own version of said feature. Again, stop to think about the following:

  • Is there a realistic use case for it? We’ve actually faced this situation several times with Hannon Hill’s flagship product, Cascade CMS. One of our competitors came out with a few features for which there really didn’t seem to be real world use case. Yet, they resonated with prospects during the demo process. We opted not to replicate the features and instead, to focus on the things that we identified to be more useful for our customers.
  • What is the problem that this feature is intended to solve? It’s always best to first talk about the goals that a user is looking to achieve and the problem they’re trying to solve before implementing a new feature. Before you emulate what your competitor has built, think about the best ways to solve the problem you’ve identified.

Always keep in mind that every minute you spend copying your competition is a minute you could spend innovating.

Too much complexity without validation

Speaking of innovation, there’s also a risk in going overboard by building a highly complex feature that has not been vetted. Des Traynor, co-founder of Intercom, once used the analogy of building a cupcake before you build a wedding cake. This is very fitting when it comes to creating something brand-new without knowing if your customers will adopt it. When you’re trying out something highly innovative, start small, get frequent feedback, and adjust quickly. Don’t go down a rabbit hole. That being said, if your product is an enterprise system, this might present a challenge because your users likely expect very robust and complex functionality from your product.

What about you? What are some of the things that you avoid with regard to your product roadmap?

 

8 tips for managing an agile product roadmap

Creating and maintaining a product roadmap is often considered one of the biggest challenges for startups and well established software companies alike. Startups need to be able to rapidly build out new functionality and to pivot quickly based on customer feedback and changing needs. Companies who have developed a highly complex, enterprise-level product have to consider how each new feature would impact the system and a potentially wide customer base. Managing a product roadmap that strikes the right balance of foresight and flexibility requires an agile and a customer-focused mindset, as well as a lot of planning and research. Here are a few things to consider.

Capture all relevant feedback

There’s no shortage of feedback channels. Your users provide a plethora of direct and indirect input when they submit support tickets. You may also consider setting up an idea exchange on which users can make suggestions for both new features and enhancements to existing ones, and comment on and vote for other customers’ ideas. Hold feedback sessions with your customers and hosts focus groups. Make sure that all of your customer-facing team members relay things that they hear from clients. Listen to internal ideas from your Services and Support teams. Most importantly, store all relevant feedback in one place so that you’re able to detect patterns more easily. At Hannon Hill, we use Productboard, but there are many other tools available. Use tags for each item so that you can better categorize and find entries.

Always start with the objective

When you’re evaluating all of the suggestions you’ve compiled, don’t fall into the trap of immediately focusing on features. Instead, approach each idea and request with the question “What’s the goal?” You’ll always want to make sure you think about the best way to accomplish a certain objective, so if you jump into “What’s the feature?” mode, you run the risk of missing out on better, more creative, or more effective ways to help your customers achieve their objective and solve their problems.

Involve multiple departments

Don’t put all the responsibility of creating your roadmap on your product team. Many departments can and should be involved in gathering customer feedback, but don’t stop there. You may have one or more team members in each department who have a knack for asking the insightful questions or for coming up with creative solutions. Invite them to roadmap and sprint planning meetings. 

Determine impact and complexity

Once you have determined the features that are candidates for your roadmap, assess the impact and the complexity of each one. Impact can be a number of things, such as added security, better user experience, fewer support tickets, or faster onboarding. Rate the impact on a numeric scale. How much of a difference will each particular feature make? Next, analyze the complexity of each feature. How difficult is it to implement? How much time will it take? What will be the impact on other parts of the system? Generally, the more things you have that have a big impact and a low level of complexity, the better. When planning your roadmap, finding the right balance is both an art and a science.

Who will work on what?

One of the aspects of roadmap planning that is often underestimated or not talked about at all is how the make-up of your product team and each individual can impact the roadmap. This is especially powerful if you have a team that’s small enough to afford you the luxury of fostering each developer’s interests and strengths and find alignment with your product goals. When putting together your roadmap, always capture who is most likely to work on what. And, of course, in an agile shop, let your developers self-assign items as much as possible.

Identify how you’ll measure success

It’s a cliché and it’s true. You can’t manage what you can’t measure. For each individual item on your roadmap, for every sprint, and for every release, capture the metrics you will use to measure success. This could include adoption/usage rates, Net Promoter Score, estimated versus actual development hours, or fixes needed.

Re-evaluate after each release

In order to maintain an agile roadmap, you have to be flexible enough to make adjustments as needed. After each release, hold a post mortem, discuss what worked well and what didn’t, and don’t be afraid to make changes based on your findings. In addition, always consider new trends, new technologies, and new problems that you need to solve. Reserve the right to do what’s right in order to deliver the best possible product to your customers at all times.

Talk about themes

Even if you are fairly certain about the features that you will add to your product in the next one to three years, be careful when talking about specifics that are too far in the future. When presenting your roadmap, only show and talk about features that are on the immediate horizon, that you know for sure are going to make it into the product in the way you describe it. You certainly don’t want to paint yourself into a corner and forego changes that make more sense at the time of rollout. Of course, you do owe your customers a roadmap, so “we’ll see what shakes out” won’t cut it. When presenting your roadmap, be transparent. Talk about themes and educate your customers about the advantages of an agile approach. After all, you want to be able to respond to current and upcoming trends in a way that optimally benefits your stakeholders rather than being boxed in by a promise you made a year ago at your user conference. When talking about themes that you will address in your product, be specific only when you can and be sure to talk about the big picture and the goals that you will help your customers achieve.

Creating and maintaining an agile roadmap can enable you deliver better products, but it requires the right people on your team and emotional intelligence when it comes to communicating with your customers. Don’t confuse “agile” with flying by the seat of your pants. Always, always be working on your roadmap. It takes a lot of research, a lot of listening, and  a lot of planning. You have to be prepared in order to be make meaningful and impactful changes along the way.

What about you? What are your thoughts on maintaining an agile roadmap?

Saying “no” for the greater good

Being responsible for the success of your company means that you strive to achieve maximum happiness levels for your customers, employees, and stakeholders. So of course, your first instinct tells you to say yes to each and every request. Saying no is so much harder, but there are many cases in which a “no” is indeed in the best interest of your company and, in the long run, for everyone involved, including your customer base. Let’s take a look at situations in which a “no” makes sense and really shouldn’t be this hard.

No to a feature

“If we only had this feature, we’d win every deal”. I’m sure you’ve heard similar statements from your sales reps. And yes, your reps are the ones who directly interact with your prospects, so it’s only natural for them to share a prospect’s comment during a demo with your product manager or leadership. Feedback from your reps is vitally important and you should always hear them out. But it’s equally crucial to teach your reps to ask questions with regard to the prospect’s objectives rather than about their preference of a specific feature. Sometimes, another vendor may have sold the prospect on a certain feature but there may be better ways to accomplish the prospect’s goals. Or maybe the flashy feature that your competitor made sound so appealing just doesn’t fit into your vision of your product and the future of the industry or isn’t even in the best interest of your customers. Understanding your prospects’ goals and identifying the ideal way to help them achieve those goals should be at the core of your road map. And that may very well mean saying no to a feature request. Take all feedback seriously but to stay true to your vision and always have the best interests of your customers at heart. Don’t dilute your product with features that might result in a quick win (as in increased sales) in the short term but that make your software hard to maintain, don’t drive the desired results for your customers, or prevent you from working on better, more impactful features.

No to customizations

Similarly, your prospects may approach you with customization requests. Typically, the younger your company and the more prestigious the potential customer is, the more inclined you are to say yes. Be cautious. Once again, consider the long term impact. How hard will it be to maintain the customization? Is a SaaS based model what you ultimately strive for? If so, how will you handle clients who have their own customized product? Does it even make sense for the client? Customization requests can spawn a lot of great ideas for your road map, so be sure to listen and ask questions. But don’t be afraid to say no to something that will hamstring your engineering and support team.

No to projects

At Hannon Hill, we’re lucky enough to have a thick pipeline of project requests from our customers, ranging from small implementations to content migrations and even large scale integrations. Occasionally, the scope of a request falls outside of what we typically provide. Clearly, we would never take on a project if we thought it to be a bad fit for our areas of expertise. We want to focus on what we do best. We will consider saying yes if a) we fully understand the scope and the risks, b) it’s something that will make future projects and helping other customers easier, and c) it helps our team members grow professionally. However, if the answer to those questions is no or if we believe that our partners are better suited and can deliver better results, it’s a no. After all, would you want your plumber to install your hardwood floors?

No to terms and conditions

Ah, contract negotiations. They sure can be tricky. As a software company, you protect yourself by having a license or subscription agreement in place which clearly states your and your users’ responsibilities. It defines warranties, liabilities and indemnification and outlines processes for remediation in case of a dispute. Sometimes, your potential customers want to negotiate the terms of your agreement or even provide their own contract. What do you do? You can either stand firm or negotiate. In certain circumstances, it may be okay to make a concession, while in other cases, you need to assess whether the level of risk of agreeing to a change is worth it. As you know, even the most rigorous QA process can only reveal the presence of bugs, but not their absence. If the potential customer’s terms specify warranties and liabilities that open your company up to a potential financial loss that is disproportionate to the value of the deal, saying “yes” would not make sense, but narrowing down the definitions of the terms would. At the end of the day, a customer who is a good fit will shy away from working with a vendor who will agree to just about anything to get the deal, even if that means jeopardizing the longevity of the business.

No to a prospect

Arguably the hardest “no” happens when you have to walk away from a potential customer. But sometimes, a prospect is simply not the right fit for your product, your service, or your company. This can have a variety of reasons. The prospect may not have the proper staff to be successful with your product. They may have unrealistic goals or expectations. They may actually need a completely different type of product. They may not even really understand their own needs or need something that is not your area of expertise. Regardless, reject the idea that any new customer is good for business. Wouldn’t you rather provide good guidance to your prospects by saying “no” than to lose them once they see for themselves that it wasn’t a good fit to begin with? The wrong fit is bad for all parties involved. It can have a negative impact on team morale and on your reputation (and thus, future business).

At the end of the day, you want to deliver the right product to the right customers under the right conditions in order to ensure long term success and happiness. And that’s why a quick yes isn’t always the right answer. Say no when it’s for the greater good.

What about you? When do you find it unnecessarily hard to say no?