Customers Can Ruin Your Vision, But They Don't Have To (Part 2)
This is a link to Part 1, and probably fits better for earlier-stage companies/products.
When you get bigger the problems shift. It's been amazing to watch Instructure move from stage to stage, and it was usually very obvious when we'd hit a new stage because the internal dialog adjusted to new topics -- getting the product out there, attracting new customers, building innovative features, fixing bugs to scaling out, etc. all in different amounts at each stage.
Anyway. Once you start to grow your company you're going to be dealing with more customers, which means more opinions and more requests and demands. Thanks to the Internet (thanks, Internet!) it's possible to gather more feedback from your customers and potential customers than you can possibly know what to do with*. And the frustrated ones will happily give it to you in droves.
That's not inherently a bad thing, but it definitely can be. It's really easy to get frustrated when you have a vocal minority of customers demanding a feature or a change that doesn't match your long-term vision. I have another blog post brewing on how product people need to play the long game, but suffice it to say a good product person will hear feature requests that make them nervous about what direction those changes will inevitably take them. Blowing off the requests sounds like a bad idea though, and vision-selling doesn't always work because there are perfectly reasonable (read: not-hypothetical, like you're cute little long-term vision thingy) justifications for the change.
The fact is, once you move beyond the early adopters you're by definition entering a customer base that is less forgiving of you-not-having-what-they're-used-to-having. You'll see increased pressure to implement things that aren't part of your vision. Parity with legacy systems is a really big deal for the less-risk-averse customer majority that is trying to convince their users that migrating to a new system is a good idea, and won't ruin their lives forever. A healthy vision is re-evaluated constantly so go ahead and take those opportunities to stop and re-evaluate. But if it still doesn't match then what do you do?
I've seen a couple things work well for us at Instructure.
The first approach is to go down a level in your discussion. Stepping back and saying "what are you really trying to accomplish" can be super valuable, and should really be the first tool in a product person's belt anyway. Sometimes you can redirect the customer's energy in a more exciting direction (like with BYU-Hawaii in the early days), and other times you can at least find a compromise that you're both ok with.
Wharton, for example, didn't want us to show final grades inside of Canvas because they had another system that kept their official grades and they didn't want students getting confused. But keeping students informed is a major part of our vision, and being able to see how they were faring in their courses throughout the semester felt really important to us. We pushed and they pushed and we were getting nowhere. So we stepped back and discovered that the vocabulary was the real issue. If we could call it something other than "final grade" in the interface then they'd be fine with keeping it. That was loads better than the custom-JavaScript-to-hide-final-grades-just-for-Wharton path that had been proposed before.
The second approach is plain old vision-selling. Ideally you'll be able to sell them on your long-term vision and they'll say "that sounds better, let's do that". Sometimes that's just a short email, but more often it's getting on the phone or (better yet) meeting them in person. The point is to actually convert the person, not to get them to shut up, so make sure you're including them in the decision, giving them a peek at the future. And if you're doing that why not also get their feedback on it? If they feel attached to the future because they had a part in it, there's the chance they'll not only stop pressuring you to change, but even help evangelize for your vision.
We've turned multiple critics into evangelists this way (not in some manipulative way, don't get me wrong. We legitimately included them in the discussion and they legitimately got excited about it), and when it works it tends to work really well. But make sure you're actually going to follow through on what you discussed/promised or you'll be worse than where you started.
The third approach only works if it's a project you intend on doing eventually, and the problem is prioritization. Basically you say, "ok, is this more or less important than X, Y and Z that we're already working on?" Don't ask unless you're willing to adjust your priorities based on the response, but it's ok to make customers think hard about what's most important. It's actually usually pretty insightful to watch that process from the sidelines.
Our client services department had the idea to start maintaining a top-10 request list early-on. This gave us a very helpful point of reference to compare priorities. If you're planning on doing both things eventually, then it seems like a great idea for your customers to help prioritize the things you're building for them, and it has the added benefit of showing them why their new feature isn't getting the attention they'd like it to. Many times the response was, "you're right, X is more important. I'll go help my noisy faculty member understand why we're not doing that."
Internal prioritization is important too. You need to have your whole team on board with the list of things you're going to build, because if a salesperson really wants a certain deal or an executive hears a noisy frustration while visiting a customer, you'll often hear about that need in a disproportionate way. Even your web forums will be skewed and can be used as fodder by the enterprising employee to get their pet feature implemented. But a strong priority lets you rationally step back and say, "ok, but is that really more important than the ability for people to log in?"
Sometimes you just can't come to a resolution. One school wanted to prevent students changing their default email address in order to keep everything on controlled systems. We assured them that their students are coming to their campus with already-established email workflows, and a new address quite often would just be a black hole. Or they'd just forward their emails and the data would leak out anyway. But their legal department wouldn't budge on the requirement. I lost track of that thread and I can't actually remember how that one turned out. Maybe we made a cheat sheet showing the students how to set up email forwarding.
I'm pretty sure this list isn't exhaustive, and these don't always work, but they're some of the ways we've tried to address the conflict between vision and a growing customer base with diverse needs. At the end of the day the product you're building should be something that attracts new customers but also continues to excite your existing customers. If your vision isn't heading straight down that path then it's probably going to be a bumpy ride. But more times than you might think it's possible to get customers on board with your vision one way or another, which ends up being a win for everyone. A good product balances happily between customer-defined and company-defined. Your customers aren't stupid or malicious, but they shouldn't build your product alone -- and neither should you.
* It's worth noting that open discussion forums are tricky things. I highly recommend them because of the insight they can provide, but they need to have a very clear purpose in mind. We implemented a "Feature Request Forum" where we want people to suggest ideas for way to continually improve Canvas. It was a really great idea, and has been super valuable at times. However, we didn't do the best job defining purpose, and since it's significantly easier to suggest a feature than to implement it, the list got huge and started filling up with "why haven't you built this yet, it's been sitting here for three years!" flameage. The goal was never to Build All the Things, so we clearly had a misunderstanding. We wanted a place where we could discuss the best way to implement new features and also hear crazy ideas we might not have thought of. We're gradually reworking our forums to get to that point but it takes a lot longer to transition there than to be explicit and clear from the get-go.
 |
| Product people, like Jedi masters, play the long game, they do. |
Anyway. Once you start to grow your company you're going to be dealing with more customers, which means more opinions and more requests and demands. Thanks to the Internet (thanks, Internet!) it's possible to gather more feedback from your customers and potential customers than you can possibly know what to do with*. And the frustrated ones will happily give it to you in droves.
That's not inherently a bad thing, but it definitely can be. It's really easy to get frustrated when you have a vocal minority of customers demanding a feature or a change that doesn't match your long-term vision. I have another blog post brewing on how product people need to play the long game, but suffice it to say a good product person will hear feature requests that make them nervous about what direction those changes will inevitably take them. Blowing off the requests sounds like a bad idea though, and vision-selling doesn't always work because there are perfectly reasonable (read: not-hypothetical, like you're cute little long-term vision thingy) justifications for the change.
The fact is, once you move beyond the early adopters you're by definition entering a customer base that is less forgiving of you-not-having-what-they're-used-to-having. You'll see increased pressure to implement things that aren't part of your vision. Parity with legacy systems is a really big deal for the less-risk-averse customer majority that is trying to convince their users that migrating to a new system is a good idea, and won't ruin their lives forever. A healthy vision is re-evaluated constantly so go ahead and take those opportunities to stop and re-evaluate. But if it still doesn't match then what do you do?
I've seen a couple things work well for us at Instructure.
The first approach is to go down a level in your discussion. Stepping back and saying "what are you really trying to accomplish" can be super valuable, and should really be the first tool in a product person's belt anyway. Sometimes you can redirect the customer's energy in a more exciting direction (like with BYU-Hawaii in the early days), and other times you can at least find a compromise that you're both ok with.
Wharton, for example, didn't want us to show final grades inside of Canvas because they had another system that kept their official grades and they didn't want students getting confused. But keeping students informed is a major part of our vision, and being able to see how they were faring in their courses throughout the semester felt really important to us. We pushed and they pushed and we were getting nowhere. So we stepped back and discovered that the vocabulary was the real issue. If we could call it something other than "final grade" in the interface then they'd be fine with keeping it. That was loads better than the custom-JavaScript-to-hide-final-grades-just-for-Wharton path that had been proposed before.
The second approach is plain old vision-selling. Ideally you'll be able to sell them on your long-term vision and they'll say "that sounds better, let's do that". Sometimes that's just a short email, but more often it's getting on the phone or (better yet) meeting them in person. The point is to actually convert the person, not to get them to shut up, so make sure you're including them in the decision, giving them a peek at the future. And if you're doing that why not also get their feedback on it? If they feel attached to the future because they had a part in it, there's the chance they'll not only stop pressuring you to change, but even help evangelize for your vision.
We've turned multiple critics into evangelists this way (not in some manipulative way, don't get me wrong. We legitimately included them in the discussion and they legitimately got excited about it), and when it works it tends to work really well. But make sure you're actually going to follow through on what you discussed/promised or you'll be worse than where you started.
The third approach only works if it's a project you intend on doing eventually, and the problem is prioritization. Basically you say, "ok, is this more or less important than X, Y and Z that we're already working on?" Don't ask unless you're willing to adjust your priorities based on the response, but it's ok to make customers think hard about what's most important. It's actually usually pretty insightful to watch that process from the sidelines.
Our client services department had the idea to start maintaining a top-10 request list early-on. This gave us a very helpful point of reference to compare priorities. If you're planning on doing both things eventually, then it seems like a great idea for your customers to help prioritize the things you're building for them, and it has the added benefit of showing them why their new feature isn't getting the attention they'd like it to. Many times the response was, "you're right, X is more important. I'll go help my noisy faculty member understand why we're not doing that."
Internal prioritization is important too. You need to have your whole team on board with the list of things you're going to build, because if a salesperson really wants a certain deal or an executive hears a noisy frustration while visiting a customer, you'll often hear about that need in a disproportionate way. Even your web forums will be skewed and can be used as fodder by the enterprising employee to get their pet feature implemented. But a strong priority lets you rationally step back and say, "ok, but is that really more important than the ability for people to log in?"
I'm pretty sure this list isn't exhaustive, and these don't always work, but they're some of the ways we've tried to address the conflict between vision and a growing customer base with diverse needs. At the end of the day the product you're building should be something that attracts new customers but also continues to excite your existing customers. If your vision isn't heading straight down that path then it's probably going to be a bumpy ride. But more times than you might think it's possible to get customers on board with your vision one way or another, which ends up being a win for everyone. A good product balances happily between customer-defined and company-defined. Your customers aren't stupid or malicious, but they shouldn't build your product alone -- and neither should you.
* It's worth noting that open discussion forums are tricky things. I highly recommend them because of the insight they can provide, but they need to have a very clear purpose in mind. We implemented a "Feature Request Forum" where we want people to suggest ideas for way to continually improve Canvas. It was a really great idea, and has been super valuable at times. However, we didn't do the best job defining purpose, and since it's significantly easier to suggest a feature than to implement it, the list got huge and started filling up with "why haven't you built this yet, it's been sitting here for three years!" flameage. The goal was never to Build All the Things, so we clearly had a misunderstanding. We wanted a place where we could discuss the best way to implement new features and also hear crazy ideas we might not have thought of. We're gradually reworking our forums to get to that point but it takes a lot longer to transition there than to be explicit and clear from the get-go.
Comments