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.

_________________________________________________________________________

“Mr. Wolf, What Big Data You Have!”

Two wolves

Wolves looking for food.

“All the better to see you Mr. Manager,” said the wolf. “When we’re called to consult for an organization, we collect as much data as possible. Only by collecting significant amounts of data can we be sure that we have an accurate representation of your business and its performance.”

“What’s that under your paw, my sales activities and funnel reports?”

“It might be, but we have advanced tools to understand what they mean, and it makes those great graphics.”

“Under the corner of the keyboard, that certainly looks like the operations scheduling forecasts spreadsheet and our performance tracking status summary.”

So goes the conversation between consultants and company managers.  Business analytics (BA) and business intelligence (BI) are hot topics. Their cousin, big data is approaching the peak on Gartner’s Hype Cycle. Mr. Wolf and his consulting cronies lean on these buzzwords for paying gigs. Especially when the economy is soft, senior management looks for magic insights that will cover their tracks, protect bonuses, and maybe even their jobs.

“If you don’t know where you’re going, you probably won’t get there.” -Yogi Berra

The core question to business analytics and business intelligence should be around having clear direction. Then, get reliable information to guide people who act on it. David White, Aberdeen Group, reported at a recent analytics conference.  Their study showed self-service data shortened decision times by 66%. Managers are 22% more likely to find important information in a timely fashion. He also commented that marketers using analytics had 50% lower churn.

For an analytics program to be valuable we’ll assume that users know what good performance in their roles requires. To succeed, managers need information in a usable format relevant to the Key Performance Indicators (KPIs) for roles. These are the people where quick, small adjustments can improve total results.  The better their perspective of the current state, the sooner and more correctly they can act for better unit performance. Graphics are great only if the display offers decision guidance.

Rather than needing to think out of the box, we need right information in the right box. Big Data is that out of the box idea.  Dispersed, unstructured information, not in our organization must be identified and massaged.  Massaging these vague sources takes energies that are better directed to satisfying customers.

This changes IT’s focus from gatekeeper to source validation and coordination across units and roles. Historically, a request would be submitted to an IT unit for a report on a specific parameter.  Too often the first version of the report needed some adjustment for the desired final product. Again, staff needs to be able to find guidance information for themselves.

Mr. Wolf, your project focus should be about helping staff understand the data, and supporting IT in simplifying systems that deliver accurate data. We may need your organization to audit data quality, just like our accountants review our financial statements.  What we don’t need is Monday morning quarterbacking to generate smoke for reporting to the board and investors.

Hand on Telegraph key

Product Design Methodologies – Match tools to program

‘When the only tool available is a hammer, the problem looks like a nail.’ – Ancient consultant wisdom.

Anybody who says they got the new product specs right from the beginning, is either on a small project or full of baloney. “Howevers” pop up as soon as the draft code appears. No matter how well done, requirements gathering is seldom perfect.  Interest groups, business functions and technology require adjustments to approach the intended product target(s).

In any well managed business project, the core focus addresses specific business issues. Methodologies, languages, and platforms are ancillary to the value proposition.  Agile process evangelists jump on requirements vagueries as validation of their methodology. Waterfall process advocates maintain that defined milestones keep project direction on scope, on measurable schedule, and highlights cost changes.  In an earlier post with Dave Schulman, we discussed a third option for design – visualization. This third method combines features of both other options.

In this short video, Bill Killam, User Centered Design, Inc.,  shares his perspective on the development options. Bill is a PhD. Human factors engineer, who does the market research to identify and guide product concepts. In the video with an earlier post, Tradesman or Architect, he talks about design being more than a single group. Here, he discusses how there is no one right answer on the design tool for a project.

For major product efforts, the traditional waterfall, or stage-gate process, is recommended as the development structure. The framework identifies and defines the core objective, constraints, and boundaries. In the sub stages, agile process facilitates rapid development and testing compounds. The build/test/learn philosophy in Lean addresses the need for midcourse correction and clarification.

A recent (8/27/14) Gartner briefing even referenced design options. The analyst commented that Agile fits mobility projects, but large concept projects require broader, longer perspective.

What factors determine your company’s design process choice?

telegraphkey

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)