Favorites

TOPICS
Cognitive Walkthrough
SMART Front Desk
Tech Dem

FREE MARKET

Clerk of the Court
$10 billion
Halloween X
Open-Source Scare
Hall of Innovation
Microethics
ProCompetition
Boycott
Comdex Demo
Counterterrorism
Security Nightmare
Browser Security
Beware of IE
Browser Wars
Firefox
OpenOffice
Mad as Hell
DMOZ
Forum

SF BAY AREA

Silicon Valley JUG
SDForum

Biz in the Trenches
Effective Product Management and Technical Sales

No paralysis by analysis here.  No pie in the sky theories either.  Just tips and strategies from the trenches to help you avoid some of the problems common to product management and technical sales in the software industry.

CONTENTS

Product Management:
Build Around Walkthroughs
Don't Let Inaction Derail Product Vision
Prioritize for Scalable Sales

Sales:
Sell What You Have Today
Hazards of the Custom Demo

General:
Dem's Rules


Posts


Build Around Walkthroughs
Successful product managers do far more than just dream up lists of cool features for their products.  As a product manager, you need to define products that solve real problems.  All to often products are unleashed on the market with decent features yet fail to maximize their usability and benefits for the users.  Some products are flat out frustrating to use.  Others may be easy to use, but are not that useful.  You can get the feeling with many products on the market today that no one thought clearly about how the product was to be used by the end customer.  And that is the exactly problem; no one spent the time analyzing real world usage of the product.  The answer to this problem is to build the product development process around task-centered user interface design principles (Prof. Clayton Lewis, University of Colorado).

Task-centered UI design incorporates walkthroughs with real data.  A critical skill for product managers is to be able to put themselves in the shoes of their customers and make design decisions as if they have no prior knowledge of their own product.  Is the use of the product intuitive?  Does the order of activities in the user experience match the steps required to solve the problem in the real world?  Is the data entered and displayed in a manner most appropriate for the those who will actually use the product?  These questions are best addressed when you submerse yourself in real world data with real world tasks -- emulating the actual customer environment.  These walkthroughs help ensure the product
has real value and a high level of usability.


Don't Let Inaction Derail Product Vision
Cost and revenue analysis are important factors in making good business decisions.  However, product managers can easily derail their products through the inaction of waiting to prove the numbers with a high degree of certainty.  New high-tech products by their very nature are forging uncharted territory.  There is often no way to know for sure exactly how the product will do and how much revenue it will generate.  You often need to rely on gut instinct and vision to successfully bring to market a new product.

If you have the luxury of sufficient time and resources for large-scale market tests, you can often obtain a fairly accurate and detailed financial analysis of your product's potential.  This information will help you optimize decisions for your product.  Otherwise, you will need to depend more on your gut instinct and vision for making your product decisions.  The right mix of financial analysis and just making decisions is at the balance where you perform the maximum financial analysis up to the point that the effort or delay of obtaining the numbers does not materially hinder product decisions.

Successfully creating and delivering a new product for untapped opportunities requires taking risks and aggressively driving towards a vision.  Don't let
paralysis of indecision impede the building of a great product.


Prioritize for Scalable Sales
Hardly anyone in high-tech ever has too much time on his or her hands, but the problem of being time constrained can be particularly acute for product managers.  As a product manager you typically have no employees reporting to you, yet you are responsible for bringing together and coordinating engineering, marketing, and sales.

The commitment to sales, unfortunately, is often the first to be neglected when time gets crunched.  You are asked to participate in sales calls for important deals, but with every sales call you participate in you have that much less time for everything else.  The further behind you get, the more desperately sales needs your direct involvement in each deal.  The solution to preventing this counter-productive cycle is to prioritize for scalable sales with ready-to-use sales tools.

Ensure that sales has high-quality compelling product presentations and demos along with appropriate product training to sell effectively.  Create presentations for both the value proposition and technical merits of your product.  Work with sales and company executives to establish expectations that product managers should minimize their participation in sales calls and instead focus on equipping sales teams to effectively sell product.  A product manager should participate in sales calls to show commitment to the customer not make up for inadequately prepared sales teams.  It is your responsibility to prepare the sales force for success.

No matter how compelling the technology,
it cannot be sold with an uncompelling story.  So prioritize for scalable sales.


Sell What You Have Today
What's more exciting to tell a customer about, your present existing features or all the new sexy features coming up in a future release?  Avoid the temptation.  Stay on solid ground and sell what you have today.

Sales teams typically fall into the trap of selling the future not because of any critical need to discuss future releases but because they are all too eager to reveal the yet-to-be-released features.  Selling the future essentially tells your customer that you do not have confidence in your current product.

Making unnecessary promises based on future features can:
  1. Delay the deal -- no one wants to pay for a feature that is not ready.
  2. Turn a regular deployment with a high chance for success into effectively a beta deployment with significantly more risks.
  3. Eliminate an opportunity to pleasantly surprise the customer since they have already factored into their expectations the upcoming features.
Of course, there are times when it is best to reveal future product features (especially with existing customers), but in general adopt a take-it-or-leave-it approach to sales.  As soon as you start promising
what you don't have, everyone's time will be wasted.


Hazards of the Custom Demo
Custom demonstrations are a mainstay of software sales, especially at the enterprise solutions level.  Usually a sales team gathers some very rudimentary requirements from the sales prospect and mixes in a healthy does of speculation.  Custom demos are almost always slapped together at the last second and inevitably live their lives never more than a single keystroke away from crashing into an embarrassing sales mess.  The opportunity costs of poring effort into custom demos is given little thought, which is particularly painful considering how many custom demos never see more than a few fleeting moments in the spotlight.  When they do see the spotlight, the results are often not as compelling as desired.  It is natural human behavior for a person to imagine a software implementation or web site being exactly what he or she wants.  It is difficult for a custom demo to surpass that imaginary vision.  Unless the customer has serious doubts about your company's abilities or indicates they definitely want to see a custom demo, try to avoid the cost of creating a custom demo.  A customer is more likely to pay for superior technology, vision, and value then for a custom demo hastily bandaged together just prior to a sales presentation.

Custom demos do have their place and can be extremely successful when done properly, but a custom demo is not a panacea for a weak sales message.  If a custom demo is created, it belongs late in the sales cycle not up front.  Keys to a successful custom demo are:  1) Make sure the customer actually wants a custom demo,  2) Get something in exchange from the customer (like access to the CEO or other important decision maker),  3) Gather requirements -- make sure the demo is not just a good demo, but that it is also the "right" demo, and  4) Allocate enough time to make a compelling demo and get customer feedback before the big presentation.  If you are going to do it, do it right.  Otherwise, the custom demo just muddies
your sales message while costing you valuable time and effort.


Dem's Rules
In the Pursuit of Productivity...
  • 3 keys to working better with other people: Listen, Listen, Listen
  • Artificial deadlines impose unnecessary inefficiencies
  • A good software engineer can write quality code more quickly than hack code
  • Document and comment software thoroughly -- not verbosely
  • Effective teams communicate well, but work is still done by individuals
  • Even in a serious business, a sense of humor can be profitable
  • Get the basic sales pitch down solid first, then customize
  • Great people have strong egos, not big egos
  • If you can't get the UI right, close up shop
  • If you don't like it, change it
  • If you are not sure why you are doing it, why are you doing it?
  • If you are not happy with it, will your customers be happy with it?
  • If it is not concise, it's wrong
  • Irreplaceable means unpromotable
  • Keep working groups small -- avoid death by committee
  • Knowledge of who to ask is no less powerful than firsthand knowledge
  • Mentoring is the exponential use of knowledge
  • No matter how compelling the technology, it cannot be sold with an uncompelling story
  • One should not talk in meetings just to hear his or her own voice
  • Quality is driven by an obsession to detail
  • Results trump effort -- reward accordingly
  • Simplicity is quality
  • Repeatable, lightweight processes are the expressways of quality
  • The Grand Illusion: It takes more time to code good software than bad software
  • Judge employees by their results not how many hours they work
  • Judge employees by how well they make their co-workers look not how well they make themselves look
  • Judge employees by how may problems they prevent not how many they solve
  • Priorities drive efficiency better than due dates


Have a comment about the views posted here?  Agree?  Disagree?  Feel free to use the "Messages and Comments" section to send your feedback.