Customers might always be right, but what they tell you isn't always useful

Happy possible-end-of-days Great American Solar Eclipse Monday!

'The customer is always right' has been a generally accepted mantra? maxim? truism? that has pretty much informed the product, service, and sales strategies for all kinds of industries for decades. And while the absolute truth and the need to adhere to this precept is certainly debatable, 'customer focus' taken more generally has developed into the operating philosophy of most successful organizations.

So while the customer is (probably, mostly) always 'right', is what they are telling you all the helpful or useful?

Over the weekend I came across this outstanding post from Cindy Alvarez called '10 Things I've Learned About Customer Development' that highlights just a few of the ways that customer input and feedback isn't always incredibly insightful or useful. Here's just one example (my favorite), from the list:

What features your customers ask for is never as interesting as why they want them. So: Direct them away from talking about the solution and back to describing the problem. Listen, pause, and then ask what it would allow them to do if they had it today. Ask what they’re currently doing as a substitute. They’ll either identify a problem (good — now go solve it) or be unable to provide specifics (feel free to deprioritize this suggestion).

In the enterprise and certainly in the HR tech space function and feature 'arms races' have been a significant driver of solution provider development and attempts at competitive differentiation for ages. This approach makes sense in an environment where customers and prospects send out voluminous RFPs and request tightly scripted demonstrations that sometimes are even spelled out in minute by minute increments. 

In an environment where business can be won by 'checking the most boxes' it just made sense for providers to, in fact, strive for the most items that could be checked off. Even if no one, customer or provider alike, is entirely sure that checking all the boxes is the best or even a sensible strategy. 

Of course there is some level of baseline capability that say a Payroll or ATS solution must provide to even be tenable - no one would argue that. But there is probably much more room for creativity, innovation, and ground breaking thinking around enterprise tech than we allow if we focus too much on 'what' we need systems to do and not enough on 'why' we think these features will allow us to accomplish.

Check out the entire list from Ms. Alvarez, there is much more food for thought in there for solution providers and customers alike.

And don't stare too much into the sun today!

What should we be working on?

My favorite things to do on Winter weeknights are to watch NBA basketball, (thank you NBA League Pass), and plow though the seemingly thousands of unread items that accumulate each day in my Feedly feed reader. So in case you really care, and I am pretty sure you don't, this piece is being drafted (who am I kidding, on the blog there are no 'drafts', it is ship or don't bother writing around here), while watching LeBron and company take on Lance Haun's Portland Trail Blazers.

But I digress.This is not Lance Haun

While grinding through my Feedly looking for some inspiration for the blog, I came across this excellent compendium of product development prioritization techniques and approaches called 20 Product Prioritization Techniques: A Map and Guided Tour. The piece is a fantastic collection of strategies and methods that are employed by product managers and developers when faced with the fundamental and critical questions of 'What product features should we build?' and 'In what priority order should we build these features?'

Both questions seem kind of easy on the surface, but for product managers and leaders they are not only very often quite complex, but how successful product leaders are at answering these questions plays a significant role in how successful (or not), their product will be. Build the 'wrong' features and current customers may defect and acquiring new ones may prove impossible. Build the 'right' features but in the 'wrong' order and risk making customers wait too long for features they need and end up losing 'bake-offs' for new customers when needed product features are not yet available.

Like I said, simple sounding questions that are often really hard to answer. And really, really important to get right. 

That's where the list of the 20 product prioritization techniques makes for a really useful starting point not just for 'product' people, but anyone that needs to assess and prioritize work efforts from a range of options, or what always seems to be an impossibly long 'to-do' list. Let's pull one example from the piece and see how it can be relevant and useful for both product and non-product, (I suppose that is just 'service') leaders. This is one I liked a lot and I think also can be pretty easily applied to say any internal HR or talent function.

Technique: Feature Buckets

The Feature Buckets technique by Adam Nash is also very popular on Quora.

Adam believes that feature prioritization varies a lot across different product types and industries and that’s why he emphasizes that this technique was thought specifically for consumer internet products.

Feature concepts should be placed in one of four buckets:

• Metrics Movers — Features that will move the target business and product metrics significantly. There should be specific goals and strategies behind the decision to invest in a product or feature (things like AARRR metrics come in handy here);
• Customer Requests —  These are features that have been requested directly by customers. They are usually incremental enhancements, but it’s important to consider them or else risk alienating users or miss important feedback coming from their usage of the product;
• Delight —  Innovative features that are internally generated based on insights in design or technology. Working on surprising and exciting features is important to delight customers and create a differentiated position in the market (c.f. Kano Model for more on this);
• Strategic – Features that are included for strategic reasons related to learning or future goals (e.g. experimentation and data gathering.)

A well balanced product release should typically include features from all of these buckets. The framework is not explicit as to the appropriate distributions among these buckets and to how to prioritize internally within each. These implementation details are left up to the Product Manager to define.

Breaking down the four components or buckets helps us see how if you could consistently deliver across all four that you would have an increased likelihood of customer (both internal and external customer) satisfaction.

In this technique you address your fundamental, internal goals, (the Metrics Movers), as well as direct customer feedback, (Customer Requests). But you also showcase your innovation, and give your team opportunity to work on exciting stuff that your customers will be surprised by, (Delight). Finally, you continue to strengthen your position as market, product, and service leaders by building towards the future, (Strategic). 

And I think you could just as easily apply the Four Buckets approach to any HR or Talent or Recruiting organization's quarterly plan as you can to a product development organization's list of potential features for the next product release. 

If you are in product management, or just have the important, (and tough), job of figuring out what the organization should be working on today, tomorrow, next week, next month, etc., take a look at some of the prioritization techniques in the above-linked piece.

No one can do everything we are asked to do. The most successful organizations know this, and they get really good at deciding what to do and what not to do.

Ok, I am out. 

Back to basketball.

Have a great day!

Users don't know what they want - but they know something

How much, or little, should product designers and developers interact with potential users and customers of the products the designers and engineers are creating?

It seems like a simple question, but if you think about it some and recall some of the famous perspectives on customer input into product development you find that the answers to this question tend to land on one of two extremes.

On the one side, you have the Steve Jobs/Henry Ford take on customer needs and wants. Jobs more or less thought customers had no idea what they really wanted, and he (and Apple), had to create that want by building amazing products that met that need (that the users didn't know they had). Ford is famously quoted as saying that if he had asked customers what they wanted they would have replied 'faster horses', instead of reliable and affordable automobiles.Ford

The other extreme, and one seen traditionally in lots of workplace kinds of technologies, is for developers and designers to build just exactly what customers request. This approach is mostly an outgrowth and evolution of internal IT shop's tendency to build custom applications based on a list of documented requirements from the end users. If the feature was in the requirements doc, it made it into the product. If not, then the capability didn't get built in the delivered product. And the IT response to downstream complaints was always, 'Well, it wasn't in the requirements.' 

So what is the best, or most effective middle ground between Jobs/Ford (customers don't know anything) and the traditional IT (customers HAVE TO know exactly what they want) approaches?

Maybe the best approach is summed up in this recent piece from the O'Reilly Radar site, 7 User Research Myths and Mistakes:

The most common reason people give for not talking to users is that “users don’t know what they want.” While that’s sometimes true, it’s not a good reason for not talking to them. It’s just a good reason for not asking them to tell you exactly what they want.

Instead, ask people about their problems. Ask them to tell you stories about how they use other products and how they make buying decisions. Ask them when they use specific products. Is it on the train? In the car? At their desks? At work? Ask them about their lives.

Users might not be great at telling you what new product they’re definitely going to use, but they’re great at telling you about themselves, and that is a very good thing for you to understand if you’re making a product for them.

That seems right to me - describing that sweet spot or middle ground between not giving a rip about what users think and the other extreme of expecting the users to tell you exactly what you should build for them.

Keep this in mind the next time you sit down with some HR tech solution provider salesperson. How much do they ask you and your team about the problems you need to address? How much do they seem interested in what makes your organization work (and unique)?

And how much do they like to talk about exactly what their product does?

You are the user. You might not know everything. But you sure know something.

Show and tell

The 'Steve Jobs was an amazingly creative thinker and leader' anecdotes will seemingly not be stopping anytime soon, and that is probably just fine. One of the latest, and that particularly caught my attention was related in this recent piece on Business Insider, Here's the Simple Yet Brilliant Challenge Steve Jobs Posed to Employees During Product Meetings.

Here is an excerpt from the BI piece:

Ken Rosen, a managing partner at consulting agency Performance Works, which worked with Jobs at Apple and at NeXT, shared one way Jobs was able to get the NeXT team thinking about design from different angles. 

The challenge was simple: each person would bring a product he or she respected into their team meeting.

"It could be anything, [even] a paperclip," Ken Rosen, who worked in marketing at NeXT, tells Business Insider. "People brought in very different products, from electronics to a paper notebook to a jump rope."

Jobs wasn't interested in criticizing or judging the employee based on what product he or she brought in. Rather, the assignment was about broadening the way the team thought about product design.

[Jobs] just really wanted to develop an organization where people knew what good products were," he says. "He wanted to develop a vocabulary and a kind of nuanced sense of judgement about what a good product really was."

I think this story is cool for at least two reasons. One, it shows a willingness and a predisposition to look for ideas, inspiration, and even answers to NeXT's particular product and design challenges from just about anywhere. Notice Jobs did not instruct his team to bring in examples of their favorite competing computers or even broadly similar products in the electronics family. He asked them to bring in any products that resonated with them.

Good ideas can come from everywhere, anywhere really.

The other reason this story is cool is that it probably helped Jobs understand better the point of view and the design sensibilities of the members of the NeXT team. It is one thing for a team member to sit in a meeting and offer comments on a design sketch or a prototype, but it is quite another for that same person to carry in an object or a product and explain to the group what it is about that object that they find compelling. The exercise wasn't really about rating or evaluating any of the particular objects that the team brought in, but rather to think and see what good product design really was.

Fun story for sure. Probably something worth trying sometime in your shop as well. And of course after reading I had to think about what product or object I would bring in for workplace show and tell...

Hmm. I do love my little Acer Chomebook, (used to write this piece). I also might consider my Adidas Superstars, (classic sneakers for the uninitiated).

Good question.

What would you bring in for show and tell?