The Rapid Innovator
A discussion on developing great products using rapid customer insight
The Rapid Innovator

Cross-functional Letter – Dear Ops Team… Love, your Sales Lead


Real letters from one professional to another. Have you considered writing a letter to one of your associates? Just send it in and we’ll post (anonymous is OK).  Keep the bad language to a minimum and try to make it constructive. We won't edit except for typos.
 
----------------------------------------------------------------------------------------------------------

Dear Operations Team,

You can trust me!  You really can...we both want the same thing:  profitable, sustainable business that is based around our core products and services.  Most often during the sales process/cycle, customers get the opportunity to meet and know one person - and only one person - from our company.  That one person carries the corporate message and philosophy to the market.  In turn, they are responsible for communicating the needs and requirements of the market (customers) back to the company and help define the business rules around engagement and pricing.  That person is typically the sales professional assigned with a revenue and/or account targets.  When this is done accurately and with integrity, it sets customer relationships up for long-term success.

I recall recently bringing a six-figure deal with a Fortune 100 biotech firm, back to our operations team for review and sign-off.  After a thorough review by everyone from the deployment engineer to the COO, it was determined that the program was solid, well-defined, squarely in our competencies and had achievable deliverables.  The only comments that the team came back with was that the "pricing is too high, and do we really want a multi-year' agreement?"  I was astounded that of all the things to spend time on, the technical/product team questioned our negotiation and pricing strategy[PHH1] !  Essentially, challenging the sales person's judgment and capabilities.  Talk about crushing team spirit!

I refer to this as 'negotiating against ourselves' - professing that the terms, pricing, deliverables may be too much or too aggressive for the customer and wanting to debate this internally.  In many instances with only a cursory understanding of the client’s business, objectives and the value our solution may bring to the customer's own business.  Believing 'we' need the relationship more than the market and/or client.  [PHH2] Instead of allowing the sales professional to build the value, insulate us from competition, position as a premium solution set or take the extra time to define -and potentially increase the scope of the engagement - you too often want to jump in and 'just get the deal'.  This more times than not sabotages my and my team's credibility and ultimately our top line and bottom line revenues.  Believe me, I want the deal more than anyone else in the room.  I live for these opportunities and if I've done my job right - not skipping steps along the way - my approach of negotiating with the customer leads to larger and more profitable deals.  

By the way - we won the deal outlined above - with the 'high' pricing and 3-year terms!

Please operations professionals - you deliver and so will I!!  

Love, Your Sales Lead

The "Steve Jobs Paradox"

 
If you’re like most product leaders I meet, you either personally suffer or see others conflicted with the "Steve Jobs Paradox". Some symptoms of this can be found in discussions that sound like the following: 

        Head of products – "I want to talk to you about this interface. I think we need to design it like this."
        
        Lead developer
– "But we're almost done, and our customers said it’s ok."
       
        Head of products
– "No."
        
        Lead developer
– "But… "
        
        Head of products
– "NO."
        
        Lead developer
– "OK, you’re the boss"

Healthy interaction style? Maybe, maybe not. But is it healthy for a product leader – the person with whom the product decision-buck stops – to take this firm of a stance on product decisions?  Balancing product leadership between a single person’s vision and the vast array of other input, such as other development leaders, designers, managers, partners, market data - and yes, customers - places a great deal of stress on any product leader. How hard should they fight for what they believe?

Few product leaders have the title (formal authority), the financial means, design sense, or just pure hutzpah that Steve Jobs had. But hey, if you believe that strongly in what will make a market-leading product - AND you have surrounded yourself with, and listen to, other great thinkers in design, development, and marketing – AND you have a true sense for the pulse of both the market as well as what customers will really value, then YES, you should behave like Steve Jobs. If you don’t have these factors in your pocket, then a more collaborative and market/customer-data approach might yield better long-term results. As a product leader, it’s your call; make it wisely.

How do you manage the Steve Jobs Paradox

Does your product plan need bi-focals?

One big discussion between product leaders, that often turns heated, is how to balance the direct input from customers with the longer term product vision. As anyone with bi-focals knows, you need two lenses to effectively navigate your world.  (BTW - Bi-focal lenses were invented by Benjamin Franklin around 1780.) Think about any product plan as having two guiding principles, 1) A long-term vision that is "market-guided" and a short-term vision or product plan that is "customer-driven".

A long-term vision (market-guided plan) is critical to any enduring market success. To quote hockey legend Wayne Gretzky, “A great hockey player plays where the puck is going to be.” As a product leader, your long-term vision must see where your puck will be in three-to-five years.  Having a clear long-term vision requires great market sensing and analytical skills to understand the future of technology trends, to anticipate customer problems, track design trends, and to foresee the evolving market landscape. A clear long-term lens gives you the confidence to develop a clear market-guided plan and will always be clearer than any customers' should be. 

However, your near term vision (customer-driven plan) is also often cloudy. Your vision is filled with priority conflicts, ideas, current perceptions, and just plain noise. Customer insight clarifies your short-term vision to ground you with a deeper understanding of the customer problems you are solving and how they want to solve it relative to what they do today. Customer insight should drive your short-term roadmap and removes all the noise from your near-sighted challenges.

Quick case study – A media technology company is developing a new iPad application. Based on market data, technology trends, etc. the leadership team has developed a clear long-term vision on the top problems they want to solve. They have articulated key user scenarios, their technology architecture, and major design elements. At what point should the development team bring in customers to validate this long-term vision to be crystal clear on their V1 product (their short-term vision)? Short answer? Early and often.

Quality customer input should foster a healthy debate within the product team and provide a great forcing function to ensure that all development efforts support a clear long-term vision, but also that the short-term vision and tactics are clarified with real customer insight.

Even optometrists do a ton of short and long vision testing before getting you into the perfect bi-focal lens. Which is clearer; A or B?

How does your team balance Vision and Customer Insight?

Cross-functional Letter – Dear Sales… Love, your Product Manager

Have you considered writing a letter to one of your associates?  Just send it in and we’ll post. Keep the bad language to a minimum and try to make it constructive.

Dear Salesperson,

I love you man… and I totally respect your challenges. I know I wouldn’t want to be the person responsible for finding business and closing deals. I know you’re busy and have a lot of crap on your plate, but I could use some help.

First of all, can you please not overpromise things to customers without consulting with me? I’m responsible for keeping the roadmap in order, clearly communicating it and trying to balance all of your needs with all of the other sales folks needs… at the same time developing a vision for our products… AND trying to work all the details with engineering.

Oh… on a related subject. Can you please not go directly to developers to ask for features without bringing me into the conversation? I obviously want you to talk to whomever you want (and you’re good at that talking thing), but if a developer (or even the VP) says they can do something, that doesn’t always mean they “should” and that it’s good for the product line.. or the company. It might be critical and I want to help you be successful with your customers, but let’s discuss the next time you have a need and be sure we get whatever you need into our product thinking. Also, if you’re looking for an understanding of which release a new feature is in, please talk with me or our program manager (we are usually in sync on what we are promising, but not always.)

I also wanted to talk with you about getting access to customers. I know they are “your” customers and you are responsible for making them happy… and continue to buy from us. But I need to talk with them too. And sometimes it’s hard to coordinate with you. You need to trust that I won’t say anything stupid, won’t overpromise what we have on the roadmap, and will always try to make you look good. I hope you agree that the more customers I actually can talk with, the better our products will be. Can we talk through how we should best coordinate my access directly to customers?

I know there’s more, but that’s all for now. The bottomline? Let’s figure out how we can BOTH be successful.

With deepest regards,

Your Product Manager

3 Simple language changes can transform development efforts

We all know how powerful the specific use of language is on communication. For example, $millions are spent finding that perfect phrase to be the tagline for our business,  contracts are bitterly disputed over the difference between "best efforts" and "reasonably best efforts", and team members are either motivated or demotivated with the twist of a phrase such as "good job" vs. "nice try."

Here are three simple language changes that can have a positive affect on buildng a development culture to drive innovative thinking, deliver better products, and just make life easier.
  1. "Listen to customers" instead of "Talk to customers" - I'm always happy when teams want to engage customers, but sometimes "talk to customers" takes a literal meaning with most of the time and energy going into actually "talking" to customers with very little real "listening."   We are always "talking" to customers - in sales meetings, during presentations, on our websites, etc. What we often mean, particularly during product development, is that we want to "listen" to more customers.  "That's just semantics!" you might be thinking. But active listening is difficult and takes practice. A simple language change can drive home the need to actually hear what customers are saying.

  2. "How might we?" instead of "We can't" - Want to innovate? This change is a must. Solving the tough problems that create real value for customers requires risk-taking, creativity,  and just plain horsepower.  Given our tight schedules, resource constraints, etc. etc., it's easy to have a first reaction of "We can't do that!" to any difficult challenge. However, if it's important to the success of the product, innovative leaders know that changing "We can't... " to "How might we.." is a critical start to finding solutions. As chronicled in Walter Isaacson's biography on Steve Jobs, Steve had to motivate Corning to restart manufacturing a special "Gorilla Glass" to meet iPhone needs. Their CEO Wendell Weeks, said to the affect, "We can't do that." That didn't stop Steve from motivating him to think "How might we..." that lead to having Gorilla Glass on every iPhone.

  3. Anything other than "Market Requirement" - The term "requirement" should possibly be banned from product development altogether. It is such a fuzzy term that whole movements have been spawned in an attempt to change the language to "user stories", "use cases", "jobs",  etc. If your company still uses the phrase "market requirement", I recommend at a minimum putting a different adjective in front of "requirement" to clarify the meaning. If you hear "We need to write market requirements", try responding, "Great! Did you mean customer requirements? Business requirements? Product requirements? Or what exactly did you mean by "market requirements". And then go further to define these terms.

Try making these three changes and see how your culture improves.

What language would you like to change in product development?

Book review - "Steve Jobs" by Walter Isaacson - A must read.

I just finished the "exclusive biography" of Steve Jobs by Walter Isaacson. Bottomline? A must read.

The book goes from his early days of inspiration when his father shared his passion for design detail, all the way through to Steve's plans to solve big consumer challenges that are driving Apple's most recent innovations. Mr. Isaacson documents conversations, meetings, and key decision moments with clarity and balance. He provides a level of research and detail that left me with a richer understanding of Steve Jobs and what made him tick.

I have always called Steve Jobs the "ultimate product manager" and I can't conduct a workshop or even talk about product innovation without discussing the iMac, iPod, iPhone, iPad, etc. etc.  This book reinforces all of the reasons I will continue to do so.

Some memorable themes that ran through the book for me were:

  • Steve's ability to inspire others with a simple, clear vision that morphed as new opportunities and capabilities evolved, even if he had to create a "reality distortion field" to bring others along with his vision.
  • Steve's ability to appreciate and leverage the brilliance of others, not just engineering brilliance that he recognized early in Steve Wozniak, but the best thinking in PR, branding, marketing, retailing and design.
  • Steve's ability to focus on the best possible products first, knowing that market leadership, revenue, and profits would follow. This is augmented with his ability to take risks, make mistakes, and learn from them.
  • Steve's interactive and iterative style of forcing multiple disciplines to work together until the right solutions were found.
  • Steve's passion for finding A players and making sure they were surrounded by other A players to build a sustainable, vibrant business.
Steve's contributions to product innovation were innumerable and this book does a great job of chronicling his successes and failures, as well as his personal challenges along the way.

I will always be able to point to Steve for inspiration as the ultimate product manager and I believe it will be hard for any product leader to make a tough product decision without asking the question, "What would Steve do?" I recommend reading this book to understand why.

What is your favorite book on Steve Jobs?

What is your investment in feedback channels?


Most companies spend a significant budget on sales and marketing activities to "tell" our current and potential customers about our products and services.  However, if you believe that it's important to "listen" to customers, then a question you have to ask yourself (and your company) is, "How much are we investing in feedback channels?"

You should, of course, include "market research" as a form of customer feedback, but if all of your "research" budget goes to focus groups, online surveys and industry reports, I'm guessing you're not as close to what your customers are thinking as you want to be, and might want to consider developing more direct ways to learn from customers.

Customer feedback channels come in many forms, such as:


 - Maintaining advisory boards
 - Consistent sales feedback mechanisms
 - Customer interviews
 - Customer service feedback mechanisms

Basically, any touch point with customers is an opportunity to gain targeted feedback.

I'm not going to recommend a budget for "feedback channels", but let's just say that if it's a rounding error on your marketing budget, or solely limited to basic "market research" then you might want to reconsider some of these more direct tools. As an example, a medical devices company budgets $250K a year to maintain an advisory board of medical technicians. This budget goes to flying in technicians and holding interesting, engaging periodic feedback meetings. The value of the learning? Invaluable. Not a bad start.

What are your primary methods for learning from customers?

Should customers have to "debug" their products?

If you're like me, you've probably received some sort of new electronics under the tree - perhaps a Kindle Fire? 3DTV? Or Roku?   I just love opening that new toy and thinking about all the cool things I'll do with it.

What I hate? Well, I've come to accept that with every change in technology, I need to invest some time in learning. But I hate when I have to "debug" my new item... and I hate it more when the company seems oblivious to these challenges.

Two quick examples -

1) Debugging my 3DTV.  I finally got around to getting my 3D Sony TV working. It's an older model (purchased way back in 2010) that needs an external sync and I want to use my PS3 to play 3D movies. I expect quick success and start my microwave popcorn. I plug everything in, we put on the glasses, and.... nothing. Instead of enjoying Johnny Depp in 3D, I receive a nice message: "Your device does not support 3D".  Now I could go on to describe the next 30 minutes in detail. Let's just say it involved colorful language, downloading new PS3 software, installing a 3D capable HDMI cable, and a 20-minute search online to find the right PS3 settings. Results? My popcorn got cold, my kids learned several new terms,
and Sony was significantly lowered on my recommendation list.

2) Debugging my new book on iPad. I just downloaded a book from the iTunes store to my iPad.  After enjoying the intro and preface, it actually showed me an "error" message at the start of Chapter 1 and skipped immediately to Chapter 2! Now I have to debug my book. The good news? I reported the bug to Apple, they responded by the next day with an apology and refunded my book price.


My point? Our job as product leaders is to make this transition to the "new" as seamlessly as possible. Many companies do a good job at this and make it easy... others don't.  Ideally you don't even notice when a company does a good job, because it just starts doing what you expect it to do.

For product developers, minimizing your customer's need to learn and "debug" is a job for good usability testing, as well as ensuring that when things do go wrong (and anticipating they will), you've provided the right information, at the right time, and with the right attitude to fix it... fast and with as little pain as possible.

If you'd like to enjoy a longer view on making products "lovable". Here is a link to my article on "Lovable Innovation - Five Philosophies for Successful Innovation" as published by RealInnovaton.com.

What Is Rapid Customer Insight?

In the blog intro, I mention "Rapid Customer Insight". Let's define what I mean by this.

After working on innumerable products - both successes and failures - and with a wide variety of teams, the core challenges I see really does come down to understanding real customer needs. It has almost become cliche that we need to "listen" to customers, but for many reasons, it seems to be very difficult for teams to actually execute. But how else can we create valuable solutions, priortize limited develop resources, and be certain of our decisions?

So what is "Rapid Customer Insight?" Simply put, it's the ability to quickly and accurately understand customer needs, issues, desires, and attitudes – and integrate these into product offerings.
It includes the specific methods and tools that a team uses to accomplish this.

One problem that we have to address in any iterative development methodology (E.g. Agile) is the need for speed. Teams are operating on short iterations of 4-to-8 weeks and might be delivering working software every 2-3 months. They need accurate customer insight in the right format, at the right time to be successful. This must be a continuous flow of information, not just data, or worse, noise.  This is what we mean by "Rapid Customer Insight" - the ability to develop feedback loops into our development efforts to guide our solutions.

What Rapid Customer Insight is not? Simply asking customers what they "want." While it's fine to ask customers directly what features they want in a product, we all know that customers can't really tell us that. They're not experts on design, the technology, or what  your team is capable of achieving. But they CAN share their problems, react to your solutions, and provide the insight you need to build great products. Most teams just need some new tools and thinking to gain this insight in ways that support their development efforts.

I'll share and discuss the tactics of Rapid Customer Insight throughout this blog.


Welcome to Dorian's Blog

Product leadership is challenging. We all want to consistently deliver successful products. However, the statistics are not good - most products fail. In fact, up to 80% of software projects fail according to Forrester (70%), Gartner (75%) and Standish (80%).  The number one reason cited? A poor understanding of real customer needs.

Given the large number of activities that product leaders are required to execute, ranging from high level market analysis to detailed specification reviews, there is no doubt why product leaders often struggle to lead development efforts using clear market and customer insight.  Also, the trend to Agile and Lean development methods require even faster and more integrated customer insight to fuel rapid, iterative development.

This blog discusses the methods, tools and issues around driving successful product development in fast-moving environments. In Jack Welch’s words, “You only have two sources of competitive advantage, 1) the ability to learn faster than your competitors, and 2) to execute on this learning faster.” We’ll focus intensely on methods to obtain “Rapid Customer Insight” and how to use this insight to drive good decisions throughout development and lead successful Agile and lean development efforts.