Building Successful Products That Sell

Featured

A successful company’s product portfolio connects well implemented technology to their customers’ business-needs.  I’m a Product Marketing Leader known for commercializing products and delivering programs that drive sales – excellent at understanding where technologies address business issues.

_________________________________________________________________________

Tradesman or Architect – Waterfall or Agile

Agile or waterfall? Anyone developing software these days is fully aware of these development styles, and probably has a passionate opinion about which is best. As with other tools, each has its place for best use.

A wise man once said, “I’m not afraid of what I don’t know. It’s what I do know that I’m afraid of.” Subtleties and depth in understanding can be the difference between a good idea failing or becoming a huge success. On large projects and in large companies, a “visionary” needs to set the direction with guidance for continuity. Small steps can be progress, but without proper guidance the program goes quickly off course.

Bill Killam, Human Factors Engineer with User Centered Design, Inc., has researched and designed numerous products.  In this interview, he comments on architecture, design, and implementation. His analogy recognizes contributions required of multiple disciplines. One concern is if an individual, or group, believes it can do everything.

As Bill says, “you wouldn’t have a carpenter to both design and build an office or professional building.” Waterfall style includes the architect, engineers, and several specialties to lay out the structure. The trades are best at making adjustments to the details.

A wise editor for McGraw-Hill made a presentation titled, “why are we so smart and they’re so dumb.” Her main point was that architects tended to think the trades people were lazy. The trades people felt the architects were arrogant. Only by directly talking can the two groups come to mutual understanding. Both sides have valid points. The Waterfall and Agile camps face a similar paradigm.

telegraphkey

Online Market Research Chat Session 2 – Statistics & Reporting Tools – JohnTidwell and Jim Hayes

“Liars, damn liars, and statisticians” was how Harry Truman categorized pollsters and political market researchers. Presentation of solid numbers implies credibility. Digits to the right of the decimal place make the information golden to the casual observer. Properly configured, projects using free and available on-line research tools with their reporting capabilities, can provide a company valuable direction. Like most tools, these need to be used properly.

Validity to market research requires a solid foundation, clearly explained.

There is a popular recommendation of walking up to random people on the street for a product opinion. That may work for mass market commodities, provided it’s on the right street.  For business software, the foundation needs a sample base of users familiar industry practices, workforce skills, and the infrastructure systems in place. For mobile products, prioritizing functionality further amplifies the need for good understanding and research.

Statistical Tools come with implicit assumptions

Accurate research requires structure around participants, criteria, question design, and a focus relevant to the objective. Obvious considerations include user technical skills, environmental factors, sample size, and even seasonality. Less obvious are technical complexities that come in the mathematical constructs.  To a driver with an average 24 psi tire pressure and a median 32 psi, it’s more significant to know which one is flat. Professional researchers should understand which tool to use, and where.  Not every problem is a nail so not every solution should be a hammer.

John Tidwell led the market research efforts at Nextel. When we created the industry solutions portfolio, he organized focus groups and customer surveys for initial guidance on what the various industries would value in mobile connectivity.

Product Requirements – Fundamental to a successful product. Conversation with Dave Schulman

“If I can’t see it, I can’t understand it,” – Einstein

The cartoon showing a tire swing by what different groups expect summarizes the product definition and requirements issue.  Fundamentally, the product must deliver on customer expectations. With business software, seldom is the customer an individual or even one group. Business performance requires accurate information to many departments. It’s needed in the appropriate form where, and when it’s needed. Simply put, everyone wants what they want in their form, at their time.

“I know you think you heard what I said but I’m not sure you understand what I meant’

Especially with projects as nebulous as new software, or even updates, requirements gathering can be tedious. Even worse than errors, seemingly conflicting requirements come from different constituencies.  Seldom is only one view ‘right’ and the other ‘wrong.’ Typically, the problem is in matching information across work flows and multiple groups.

A successful project will have defined plan and scope addressing the comprehensive list of requirements. Admittedly, some requirements fall beyond the ‘must have’ group, and more in the ‘nice to haves.’ Clearly requirements and niceties establish better the project budgets and scope. User experience (UX) also factor into the deliverables.

Prioritization of features, functions and stored information take additional significance when the product includes a mobile component. Field workers may move through job tickets in multiple ways, yet it is important that required information is available. Powerful mobile devices still depend on a network connection for heavy memory and computing. On the other end of the transaction, the back office needs accurate and timely information. The estimating group needs details on actual task times for better future estimating. Operations may need progress reports for project management. Absolutely, accounting needs accurate time and material reports for billing, payroll, etc.

Project tools are commonly in the Waterfall and Agile camps.  Each tool has its disciples and detractors. Visualization techniques provide a representation to help 2define the product. The technique can be used with both tools to shorten development time with better customer satisfaction. Beyond just ‘seeing screens,’ it reflects flow between them.

In this video, Dave Schulman, InfoConcepts.com, talks through the value of visualization to all parties in the development cycle (SDLC)

telegraphkey

Market Research Chat with John Tidwell, PhD. – Session 1, Online Tools

Paraphrasing a Peter Drucker quote, ‘The right answer to the wrong problem can be more than wasteful. It can be destructive if it leads a business down the wrong path or delays action on the important issues.’  From product concept through buying preference, and customer satisfaction, accurate market information is the foundation to success. Good research can identify saleable products and operations valued in customers’ business. Features that don’t fit the process represent break-points.  Operations that frustrate users block deployment or general user acceptance.

Online tools bring survey capabilities to the masses.

Just as renting premium tools doesn’t mean a final product will be well crafted, research tools, like Survey Monkey, Zoomerang, or web analytics doesn’t guarantee a good answer.  For that matter improperly used premium tools, SAS or SPSS, won’t produce real insights. Solid information follows when a well constructed survey reaches the target market users in a clear and measurable format.

Results demand proper analytics positioning information in right context for action.

John Tidwell led the market research efforts at Nextel. When we created the industry solutions portfolio, he organized focus groups and customer surveys for initial guidance on what the various industries would value in mobile connectivity. Recently, he and I had a series of conversations around the topic of market research and the availability of sophisticated tools via the Internet for little or no cost. Structural issues like sampling, modeling and scaling are topics where the professional researcher adds value. Here’s what John had to say.

telegraphkey

NDA, protected information or no talking?

No business of any size is the effort of one person. Contributions across several areas and expertise from multiple people make the best products.  The question is when to share and with who for help.  At several recent meet-ups to help developers and start-ups, the need for non-disclosure agreements (NDA) stopped conversation. It’s generally understood that there is no intellectual property (IP) protection for ideas or practices that are common knowledge. The grey area comes in defining common knowledge. Discussing a new application in a room of developers is probably not a good idea. The first to file would probably get the protection, not necessarily the idea creator.

One potential solution to keep the discussions open is to talk at a directed level of abstraction. There are several adages about the difficulty of making something simple or short. But that said, truly understanding the business need or product value, and it can be discussed in broader, simple terms.  For example, at one meeting a tinkerer wanted to hire a coder to build out his idea. He wanted everyone in the meeting to sign an NDA before presenting. All he would explain about the idea was that teachers are not capable of teaching math and science. The group couldn’t figure out if he needed machine level coding, instructional programming, multi-media assistance or social media guidance. About all we knew was that he was probably would not win many math or science teachers as advocates for the final product.

At a different session, a person started with a similar request for tech assistance. He clarified the idea as a tool for people to monetize personal information and connections across social media. This led to connections with a coder and a UI professional. Two months later he has a product in testing and discussions with financial backers.

Speaking of financial types, NDAs and most investors don’t mix at the proposal stage. Investors are in the business of being pitched new ideas. They want demonstrated capabilities with market understanding and business acumen. They see plenty of pitches that often have overlapping capabilities. No need to sign a document that puts them at risk of getting into a prospective dispute. In building the mobile business portfolio at Nextel, I had a developer get extremely angry because I wouldn’t back his app. What he didn’t know and I couldn’t say was that seven other developers had a similar idea and they had working products.

Since I’m not a lawyer and don’t play one on TV, I won’t pretend to offer advice on the need for an NDA.  The folks at Womble, Carlyle in Tyson’s Corner actively practice in the software area, with lawyers specializing in technology areas from starting the business, to contracts, to mergers and acquisitions. Todd Harris in that group made a series of guidance videos for reference, to help answer questions.  In the first episode, he talks about why the NDA is needed and by whom.  Below, in the second episode, he talks about what is covered by confidentiality agreements.

telegraphkey

Idea, App, Product, Business

Pitchfork of moneyAnytime developers get together, discussions will range across the spectrum of app status and financial valuations.  Even the VC community talks about their latest find and how it will be the next blockbuster. Some folks believe they have a great idea that just needs some coding tweaks to become the next big thing that will make them tons of money – fantasy status to the smart financial folks.

Substantial prospects start only when the idea becomes an executable app.  Few people can actually visualize at a conceptual level, even when talking to the best of story tellers. Those who can visualize will want tangible evidence that demonstrates viability and usability. There are few truly unique concepts.  The real differentiator comes with execution and scalability. Working code is not an app either.  Only code that has been sufficiently tested can be called an app.  Without adequate testing, it is a science project with potential. The app level needs a system for provisioning a user. Nothing is more frustrating than no ability to get to market – ‘for want of a nail.’

Once the app is complete, it could move to product status.  The major differences are that a product has infrastructure systems servicing the multiple constituencies. These systems start with scalable provisioning, then add billing, documentation, and customer service for example. Infrastructure needs integrated testing and end-to-end performance validation.  Too often there is fundamental failure to acknowledge, or understand, the need to service the customer. Bad experiences with the first few users kill prospects for winning evangelists for the product growth. Value ties to sales, which requires awareness.

A business starts with organized efforts and materials in the product’s go-to-market plan. Without sales – no customers and no revenue.  Further, a business has broader offerings than a single app. Business implies more products, accessories, upgrades and related offerings. When the dot com bubble burst, several found they had products at best, not a viable business. Higher valuations come with long term prospects. Products built to address a market need or business pain point always have a future. Technologies are just glitter that gets replaced over time.

Currently in the software markets, the ultimate business is a concept that becomes a platform. Think about search engine Google, messaging Facebook, and directory LinkedIn. Other high valuations come with key, market access capabilities like WhatsApp.

Stage Indicator – maturity range Valuation(1)
Idea Mental fuzzy concept to working alpha code Big bucks – with board game maker name printed on them
App Customer trialed beta code to listing in an app store Percentage of dev. costs and whatever else you can get. (Price and value are not the same.)
Product App selling well in store supported by business systems for finance, sales development, customer support, messaging,
Business Multiple apps with extensions accessories and affiliate sales in store and supported by business systems for finance, sales development, customer support, messaging, etc. Multiples of 5-10 X annual earnings, to more money than can be hallucinated.

(1) For a serious overview on valuation, see ‘Valuing Startup Ventures’ by Ben McClure on Investopedia.com (http://www.investopedia.com/articles/financial-theory/11/valuing-startup-ventures.asp)

The Whys Presentation, a foundation

ColonialResentTelling stories is a popular format for presenting material that’s easy for a listener to understand.   In trying to raise funds or to make a sale, the presentation needs engage quickly, and be succinct. The presentation won’t close the deal, but it does open the discussion that leads to a deal.

Here are why questions to focus your story’s content for better engagement.

  • Why does the market have the issue you’re trying to solve?

The foundation to any business product’s value is how it addresses a business issue. Useful is better than cool to business.  It’s not enough for one company to have an issue or for the issue to be occasional.  Address the business issue and not the technology.

  • Why are you talking to me?

If the audience doesn’t see a reason for their involvement, they’re lost in 15 seconds. The other side of this question is knowing your expectations from the audience.

  • Why hasn’t someone else come up with a solution?

Everybody likes to think they have a unique idea.  Typically, the difference between ideas is execution. If you’ve identified a real issue, clarify why yours is the best answer. Listen for feedback to understand where the story can be better developed.

  • Why won’t markets use another way to make a fix?

Clearly state the alternatives. They exist, including doing nothing. Enumerate the advantages and vulnerabilities to the options in a manner that puts your product in the best light. Customers can be ingenious at taking your observations, then developing their solution.

  • Why won’t somebody copy your product or idea? 

There was a time when development and set up expenses inherently built long delays into product knock-offs.  Patents are not ironclad protection and will be expensive to defend. The best medicine here is to be good, be fast, and be likeable.

  • Why will prospects buy from you?

What is there about your organization that makes it compelling as the provider for the solution?  Know your efficiencies and explain in simple, short terms. Beware of talking yourself into a hole from which you can’t deliver.

  • Why is your team the right group to run the business?

It’s one thing to have an idea and build a good beta product. Demonstrate that your staff and organization understand the industry issues as well as how to execute reliably.

  • Why should anyone put their money into the venture?

A customer wants to see financial improvement from their operation.  The investor wants to see a return on the money. Demonstrate character and responsiveness that validate the contribution from the product. A smart VC will want to know why you need their money, but more importantly, what else they can contribute to the business.

  • Why don’t you have more customers today?

The best validator for a product is paying customers.  Other customers feel more comfortable if they feel others have worked through the development issues and found value in the product. They all want to be early, but none wants to be first.

 Investors use the same gage to validate their participation. Tongue in cheek, they call it, the greater the fool theory. “I might be nuts to buy in, but somebody else did too, and someone else will pay more than me.”

 With answers to these foundation questions, the base content is available to build the VC pitch and sales support materials. Listen carefully to the questions, which are actually golden insights. Be sensitive to time because no audience will stay engaged forever.  Remember that in the end it is a story with a hero. Make your product the hero. The best presentations are more story and dialog than diatribe.

Related reading:

telegraphkey

 

Launch Readiness Review – Bakers Dozen Checklist

Michelangelo reportedly said, “A detail doesn’t make a masterpiece.  A masterpiece is made of details.” Similarly, a successful product launch needs to have the details in the functional ecosystem fully prepared.  Products successfully pass rigorous testing, but the support and enabling systems only get marginal review.

Once engineering says the product is fully market ready, it needs trialed in the production environment.  Any adjacent processes, applications, or services in the production environment need performance validated.  Of course, this includes the human support systems being fully trained and apprised of what is expected.

Order entry, CRM and sales commissioning services connections to billing and payroll need proven. (We had an experience that uncovered a rogue, order entry system in one region.)  If there are any royalty payments associated with the product, those need testing and validation to be audit worthy. No matter how many products have launched before, each addition or change needs systems validation.

Here is a quick baker’s dozen checklist to review before making any sales announcement.  Customer satisfaction starts with ordering and activation.

Download (XLSX, 10KB)

Product Marketing, no really what is it?

Over the last week, I’ve had conversations with several people who do related but different jobs that all think their job is product marketing. I talked to a marketing communications person with a journalism background who writes papers, articles, manages a website, and believes that’s product marketing. An engineer that develops product, and occasionally talks with customers also believes he is product marketing.  Designers fall into a category similar to engineers. The salesperson who meets with the customers is convinced that’s product marketing and thinks he knows all customer wants.  So the question becomes, what really is product marketing?

Peter Drucker said, “The role of a company is to attract and retain customers.”  He requires these customers generate revenue that support continuing operations for the company’s stakeholders.  This means there’s also a financial element to product marketing.  I haven’t yet had a finance person tell me they were product marketing. The key word here is yet, and I don’t work in financial industry.

The best answer comes through a position balancing across functions with all of these groups.  A solid product marketing person brings together internal and external resources required to develop, maintain and grow products that address customer needs.

A salesperson builds relationships with the customer to understand their business environment including, the technology and people.  The communications person polishes the product capabilities story for market viewing consistent with the company’s branding and image.  The engineer and designer are more the manufacturing side to the final product.  Each of these components is important and valuable to the company to service a customer.

Key performance indicators reflect how each of these roles are more accurately defined.  I’ve had salespeople call, excited because they wanted a bigger price discount for a marginal account.  They were quota driven instead of profit oriented.  Marcom people do a fine job of generating customer interest, but don’t always understand nuances as to why the customer is interested or how the product fits the business operation.  They measure themselves in numbers of leads.  All too often those leads are little more than names that came to get a freebie or maybe read a paper. Designers and engineers frequently measure themselves in terms of product features, coolness, lines of code, and other things that don’t clearly address market needs.

Product marketing leads this team of groups to establish, maintain and grow a balanced product portfolio.  The balance requires a profitable basket of products that address a range of opportunities in the customers’ value chain.  When we first launched data products on mobile phones, we had a dozen candidates that did essentially the same thing – tell a worker about the next delivery or pick-up.  To broaden opportunities, products for time records, asset management, and project management were added to the portfolio.  This broader product line allowed the partners to also profit by not competing for same target customers.

The challenge extended to helping the sales team understand the differences.  Where the retail channel sold commodity voice service, data solutions required deeper understanding of the applications and the customers’ industry. Product marketing translated features into customer benefits and created selection guides.  The business sales teams brought back issues their customers started sharing as those customers now started to perceive us as interested in their business.

Designer/engineers brought great new ideas and capabilities to the party as technology improved. Processor, memory, display and transport improvements each expanded capabilities.  Product marketing focused on what customers would pay real money to use.  At times, the slow response frustrated the engineer.  Other times, we had to work with customers and sales to recognize the value. Putting the mobile Internet in a field person’s phone was initially perceived as a distraction from productivity. We had to share the broader vision and value to the capability.

Product management works months or years ahead of today’s sales goal.  This means bringing new technologies, practices, and capabilities into products in a timely fashion. Too early means long sales development.  Too late and the market has moved on.   This requires a balance across customers’ with capabilities for offerings that meet their needs, which translates to a reason to buy.  Financial issues around pricing, prospects and profitability are significant enough to deserve a separate post later.

I’m interested in your thoughts and experiences in the role for product marketing.

telegraphkey

Do you have a hidden product?

Last week I attended a Tech Breakfast in AOL’s offices with several start-ups and government contractors.  Once again, I heard comments that made me wonder how many companies have similar issues.  A Business Dev. person talked about having many projects that tend to be repetitive of the same basic services.  A few minutes later, he talked about how sequestration slowed business. He also commented that agencies were able to buy products, but they couldn’t hire contractors.

Especially with government, contractors working in security audits and security reviews have similar programs that they run for multiple groups, each based on separate RFPs.  As they describe it, they bring in techs who run the same test series such as those for security breaches and firewall connections.  Even the sales folks talk about how it’s a routine project that the text find pays, but is not particularly rewarding.

The work is routine and has the ability to be scaled.  If the contractor could productize what they are repeatedly doing, they could improve margins and reduce cost for their customers.  From what I hear in the descriptions, it sounds like these organizations do the same things without realizing potential efficiencies.  They’re doing things the way they’ve always been done.  By putting product definitions and an ordering process in place, they could make life better for everybody.

The classic contracting practice is to sell an original base, then charge for add-ons, changes and scope expansion. It might help to recognize;

  • Core efforts commonality
  • Typical, common add-on modules
  • Cross group commonalities

telegraphkey