Category Archives: Developing Products

20
Jul

How do ISVs incorrectly estimate the value prospects see in products?

Posted by | Categories Developing Products

ISVs often incorrectly understand the value estimates prospects come up with for product offers. In my experience this wrong understanding leads to decisions to price products below fair market value. These ISVs make related decisions to proceed with a problematic product marketing plan and, too often, fail.

Clayton Christensen’s book “Competing Against Luck: The Story of Innovation and Customer Choice” presents the notion of Jobs Theory for product marketing. Jobs Theory, as I understand it, provides product marketers with a way to conceptualize their products from the perspective of prospects. This transformation of view point is absolutely the first step in framing a useful estimate of the value (if any) target markets may attach to a product. ISVs unfamiliar with jobs theory are hard pressed to wield a tool with comparable power and, therefore, often mistakenly estimate market perception of product value.

Jeff Thull’s book, “The Prime Solution” includes a lengthy section on the importance of value for selling products to large organizations (Mr. Thull is well known for promoting a sales theory, “The Complex Sale” for markets characterized by these same large organizations. From my own professional experience I can confidently endorse the usefulness of his theory).

One example comes to mind as typical of how easy it is to base value estimates on simply the wrong data: Mr. Thull recounts a story about a product sale to one of these large organizations. This business had been losing money for years in one division. The sales team had qualified this division as a reasonable candidate for its software product, but mid level management at the division expressed little interest. Despite losing money, this division was still budgeted for operation. So line management saw no reason to do anything. Their “job to be done” (to use Mr. Christensen’s terminology) was to operate successfully within the budget, regardless of whether or not the parent organization was making money or not.

But when the sales team changed its focus and had some conversations with managers within the parent organization who actually had responsibility over the ongoing losses experienced at the division, they heard a different story. Senior management had a “job to be done”: “we need something to help us stop losing money and start operating this division profitably, once again”. Once the sales team identified a contact in the senior management team, the dialogue could proceed.

I hope readers can see how different prospects at different organizations can come up with widely different estimates of the value of software solutions. Market prospects at different levels in a decision-making process need to be surveyed before estimates of value can be correctly formalized for products.

ISVs otherwise unfamiliar with Mr. Christensen’s “Jobs Theory” and/or Mr. Thull’s Complex Sales methods come to a wrong conclusion, most of the time, on market value for their product offers. Therefore, the “Measure” step in Eric Reiss’ “Build, Measure, Learn” has to be “done right” if useful results are to be had from the effort.

4
Jun

Successfully Promoting Apps to Enterprise Business Requires More Than An Appeal to Mobile Users

Posted by | Categories Developing Products | Tagged , , , , , ,

2 Color Design Hi-Res From the recent financial results of leading software vendors — Microsoft, Oracle, SAP and more — it should be apparent enterprise computing remains the most lucrative software market in mid 2015. So early stage tech businesses (ISVs) need to conceptualize, architect, and build solutions on a foundation including a clear understanding of what enterprise computing is all about if a revenue plan includes marketing to enterprise business.

Unfortunately, ISVs with CRM apps written for iOS who expect business consumers to buy simply because they use iPhones are not likely to succeed. Sure these apps will work fine — to an extent — for SMBs, but not for enterprise computing. A scalable architecture is absolutely required for this market segment. After all, enterprise computing includes PCs, Mainframes, and mobile devices (including tablets as well as smartphones). So it makes sense to either include a PC version of your solution, which will work seamlessly along side your client for the iPhone and iPad. If you do not have the PC solution, then you must have the hooks in place to allow users to plug your solution into one built on a scalable architecture addressing this market requirement.

All of the above may seem rudimentary to readers, but I was recently approached by an early stage business with a CRM built for iPhones, only. When I asked about clients for PCs, etc, my questions went into the void and my email exchange abruptly terminated. So early stage ISVs often combine a promising solution for a solution businesses may really need, with a very limited and inadequate understanding of just how users will actually consume the solution.

Of course, building your solution for an enterprise computing market doesn’t stop when you have successfully equipped your solution with a scalable architecture. You will have to also use a method of authenticating users. So here, too, you should choose the method most familiar to the market — in all likelihood something built to communicate with Microsoft’s Active Directory.

The list of critical architectural requirements does not stop with the above couple of examples. There are more, in fact too many to discuss, completely, in this post even in no more than broad terms.

If you have a solution you think is promising for enterprise computing, but are not familiar with the requirements posed by this market, you need to add someone to your management team who can fill this gap. Our temporary VP of marketing plan can execute on this role until you identify a right candidate for the spot. Please contact us to learn more.

Ira Michael Blonder

© IMB Enterprises, Inc. & Ira Michael Blonder, 2015 All Rights Reserved

14
May

Amtrak Derailment in Philadelphia surfaces important points likely to be on any technical product development roadmap

Posted by | Categories Developing Products | Tagged , , , , , , ,

2 Color Design Hi-Res The chronicle of a tragedy that befell an AMTRAK commuter train on May 13, 2015 includes points worth consideration by any product marketer working on solutions for process control, and even the Internet of Things (IoT). These points should also be of interest to anyone with a role in an operational risk management (ORM) effort for mechanized mass transport.

Comments on the most prominent of these points, namely AMTRAK’s inability to implement the Positive Train Control service:

Just because a customer has either purchased a solution, or committed resources to a solution, does not mean the customer has taken the steps required to move forward on it. As Jad Mouwad wrote on May 13, 2015 in the New York Times in an article titled Technology That Could Have Prevented Amtrak Derailment Was Absent, Positive Train Control (a complex solution leveraging real time data from sensors to manage the performance of locomotives on rails) ” . . . might have prevented the derailment of a Metro-North commuter train in the Bronx in December 2013 that killed four people and injured dozens . . . ” and the Philadelphia tragedy, as well.

But Mouwad writes ” . . . the absence of the technology has come up repeatedly.” Bottom line: Positive Train Control looked great on paper, but the task of applying it, Mouwad writes, ” . . . involves fitting 36,000 wayside units and equipping 26,000 locomotives according to industry figures.”

The takeaway for product marketers? Putting together a “complexity assessment”, complete with an estimate of likely impact on customer ROI, should be a mandatory feature of a product roadmap.

In turn, and from the customer side of a purchase decision, an internal operational risk management (ORM) effort should also discount the usefulness of a purchase like Positive Train Control based on likely internal obstacles to implementation. Of course the discount should be applied against the ROI expected from the investment. A governance plan should include the steps required to overcome these obstacles to ROI.

If your business is developing solutions like Positive Train Control, but you lack an internal product marketing management effort to craft a promising roadmap for your rollout, please do not hesitate to contact us. We bring to the table over 30 years experience promoting and selling technology solutions (hardware, software, services) to the kind of complex enterprise customer fitting the presentation of AMTRAK (unfortunately), in this example.

We can also help customer organizations looking to improve the performance of ORM functions in order to better prepare for tragedies like this one.

Ira Michael Blonder

© IMB Enterprises, Inc. & Ira Michael Blonder, 2015 All Rights Reserved

16
May

Apple Apparently Plans on Acquiring Beats Electronics

Posted by | Categories Developing Products | Tagged , , , , , ,

According to an article written by Ryan Faughnder and Chris O’Brien, titled Apple may be buying Beats Electronics for $3.2 billion, which was published on the LA Times web site on the evening of May 8, 2014, on May 8, 2014, the Financial Times published a report of talks between Apple and Beats Electronics. The driver for the report amounted to a strong likelihood Apple intends to acquire Beats Electronics. A sale price of $3.2 billion is included in the LA Times article.

In a short video clip titled ‘Apple: Can-Kicking’ Alan Livsey and Joseph Cotterill of the Financial Times opine on the merits, or lack thereof, of Apple proceeding with the acquisition.

Joseph Cotterill sums up what will likely prove to be a popular investor concern about the deal: “Where else could [Apple] have spent the $3 Billion?”

Messrs Cotterill and Livsey go on to delineate why the deal fails to make a lot of sense:

  • iTunes, which back in 2008, according to Mr. Cotterill, amounted to a $16.00, per subscriber, business, is now just a $1.00 per subscriber business. He sees the Beats subscription service as, essentially, more of the same
  • Mr. Livsey characterizes Apple as the quintessential brand, and wonders why it makes sense for them to buy another heavily branded business — Beats Electronics
  • Finally, Cotterill notes Apple will not be buying the Beats Electronics hardware business, just the subscription engine they have developed, which though highly regarded, still has far fewer subscribers than Spotify

Is this Apple’s attempt to build its own SaaS, cloud offer? In other words, is the Beats Electronics subscription service Apple’s attempt to cobble together their own version of Microsoft’s highly successful Office 365 cloud SaaS offer? Certainly the target market is entirely dissimilar (SMBs and enterprise businesses on the Office 365 side, vs music lovers with a credit card for Apple/Beats side), but the recurring revenue, low maintenance, presumably high margin business is very much the objective of both attempts. Presumably we will all know a lot more about the rationale behind the deal if Apple makes a formal announcement about it.

Ira Michael Blonder

© IMB Enterprises, Inc. & Ira Michael Blonder, 2014 All Rights Reserved

18
Feb

CloudShare’s Development and Testing Offer Meets the Requirements of Modern Software Prototyping Best Practices

Posted by | Categories Developing Products | Tagged , , ,

Many enterprise IT organizations, and their peers in the public and not-for-profit sectors have embraced software prototyping. A review of the components of an industry-standard software prototyping procedure can provide decision-makers with the qualifiers they need to choose the right solution for their specific needs. A handy guide, in PowerPoint form, can be found in a presentation by Vishnu Chaitanya reddy Nara, Software Prototyping, which is published by Louisiana Tech University.

CloudShare’s Development and Testing offer meets, or exceeds the basic requirements of an industry standard software prototyping process, as it is described in Vishnu Chaitanya reddy Nara’s presentation.

The presentation summarizes three different approaches to software prototyping:

  1. Throw Away Prototyping
  2. Evolutionary Prototyping
  3. and Operational Prototyping

Vishnu Chaitanya reddy Nara writes about “Throw Away Prototyping”: “Throw away prototyping is one type of approach where an initial prototype is built mainly focusing on the poorly understood requirements” (quoted from a PowerPoint Slide Deck published on the web site of Louisiana Tech University. A download link for the slide deck has been provided in the paragraph above). Early stage Independent Software Vendors (ISVs) are prime candidates for “Throw Away Prototyping”. Their “ready, fire, aim” approach to software product development must be built with as close to a self destruct mechanism for concepts as possible.

Certainly there is no better method of rapidly assembling development tools, operating systems environments, and hardware infrastructure, than to make use of virtual computing resources for this purpose. CloudShare has the features required to make this type of prototyping not only possible, but profitable, when the annual cost of $2400.00 for a TeamLabs subscription (permits 3+ users to access a virtual development environment) is compared to the cost of acquiring disposable hardware, and software for a similar effort, albeit one handled on premises .

The foundation plank of a successful “Evolutionary Prototyping” method, the second of three noted above in our bullet list, Vishnu Chaitanya reddy Nara writes, is a set of ” . . . well understood requirements.” (ibid). If we look at this approach, from the perspective, once again, of an early stage ISV, we see a need for “Evolutionary Prototyping” once our “ready, fire, aim” method has revealed a bonafide product development opportunity for an enterprise computing market.

Recent quarterly earnings reports from some of the leading mature ISVs (Microsoft®, Oracle®, and IBM®, to name three) have indicated strong market demand from enterprise users for Software Defined Data Centers (SDDCs). SDDC, one can argue, is a safer step along a path to reliance on cloud computing resources for the kind of large communities of computing uers typical of enterprise business, etc. Of course, the underlying assumption powering SDDC is a combination of on premise computing for data communications of company proprietary information , with cloud Infrastructure as a Service (IaaS) resources.

Once again, CloudShare’s TeamLabs offer can certainly be used in an Evolutionary Prototyping approach to an SDDC system.

Perhaps the final variant presented by Vishnu Chaitanya reddy Nara, “Operational Prototyping”, represents the most promising method of the three, at least for CloudShare’s offer. This approach requires the user to be able to implement “Throw Away Prototyping” and its “Evolutionary” sibling, as required. Certainly it will be substantially less expensive for an early stage ISV to use the TeamLabs subscription offer to deliver, over the long term, for enterprise customers in need of an “Operational Prototyping” model for further systems development than would otherwise be the case with an on premises computing approach.

Ira Michael Blonder

© IMB Enterprises, Inc. & Ira Michael Blonder, 2014 All Rights Reserved

24
Dec

Product Development Assumptions Must Factor In Predictable Regulatory Positions

Posted by | Categories Developing Products, Product Marketing | Tagged , ,

I’ve posted to this blog on earlier dates on the topic of Google Glass. I don’t like the product for a number of reasons. This list includes concerns about regulatory agencies efforts to prohibit sale of the product. I think it’s mandatory for technology businesses to factor in the stance of regulatory agencies when they think about building solutions for markets. So, with Google Glass, and the new text to speech email reader products automotive manufacturers have announced, any useful product plan must anticipate likely regulatory action to ban the sale of these products for specific markets. Further, this type of product plan should include an assumption of how likely regulatory efforts will affect market size. The most notorious example of computing solutions crossing the regulatory line is, of course, Napster.

So where, if at all, does it make sense for technology businesses to undertake development for these markets? I think this type of “edgy” product development only makes sense for very large businesses, like Google. They have the financial resources to weather the losses likely to result from these types of efforts. The only legitimate driver, in my opinion, is an effort to brand the company as the leading edge of product innovation, and, further, one with the courage to question the positions taken by regulatory agencies.

This type of branding effort carries with it the “rebel” label, which has proven itself to be a very attractive label for the U.S. consumer market. Apple wielded the “rebel” brand to great positive effect. Perhaps Google is after the same territory.

But it’s very risky for early stage technology businesses, especially those running on self-financing, to challenge regulatory agencies. There are better ways to achieve a rebellious brand as a market leader than this type of effort. One last word on this topic: from what we’ve read recently, it looks as if European regulators may soon enforce privacy policies likely to substantially raise the cost of operating cloud services in an approved and legal manner.

Ira Michael Blonder

© IMB Enterprises, Inc. & Ira Michael Blonder, 2013 All Rights Reserved

23
Dec

Gauge Market Behavior to Choose Products for Development

Posted by | Categories Developing Products | Tagged , ,

Technology products should never be developed simply on a hunch about important problems markets need to solve. Business intelligence must be gathered from markets to support allocating any resources to build products.

I think products like Google Glass are an example of how not to develop products. Google appears to have designed this product to solve a common need for a less obtrusive method of maintaining a constant bi-directional connection to electronic communications than currently offered by smartphones, tablets and PCs. But I don’t think this need actually exists. In fact, if one reads an article authored by Matt Haber and published to The New York Times website back on Sunday, July 7, 2013, A Trip to Camp to Break a Tech Addition one gets the sense the market is waking up to the debilitating nature of constant bi-directional electronic communication. Numerous studies point to much lower levels of productivity for people who do not take breaks from work.

My conclusion also applies to a new trend in automotive features development, which is proceeding in precisely the same direction. In other words, the major automobile manufacturers are adding text to speech computing systems to vehicles. The purpose of these systems is to permit drivers and passengers to listen to email, and text messages read to them while in transit. Once again, I don’t think there is a pressing need in the market for mobile data communications for this type of device.

Interestingly enough, in both the case of Google Glass and the automotive text to speech systems, there are serious questions about whether regulatory agencies will even permit the marketing of either device. Regulatory agencies are seriously concerned about the chance for driver distraction implicit to either product. So whether market participants actively pass up on buying these products, or not, may be entirely inconsequential. Regulatory agencies may prohibit sales of these products, altogether.

Ira Michael Blonder

© IMB Enterprises, Inc. & Ira Michael Blonder, 2013 All Rights Reserved

23
Aug

Finding Substantial Value in Collaborative Product Development with Market Peers

Posted by | Categories Developing Products, Product Marketing | Tagged , ,

Last month we published a post on the risk early stage tech businesses take when they develop products for other products built by third parties. The example we cited in our post was a familiar one, Microsoft and Intel’s collaboration over the last 25 years. The key points about this collaboration? Intel produces the next generation of is X86 firmware and Microsoft debuts a new version of Windows. The danger implicit to this strategy, as we wrote, amounts to predicating the success of a product on the success of the other product. The historical example of why this type of inter business collaboration can work to the detriment of one, or both of the partners, can be found in the recent phenomenon (over the last 5 years) where tech consumers have switched from the devices built on Intel’s X86 firmware to devices built on ARM Holdings firmware. Examples of devices built on the latter architecture include most, if not all, of the products we refer to as small, smart mobile devices.

The kind of collaboration we noted, as it turns out, is actually nothing new. In an article titled Capturing the Value of Synchronized Innovation, Jason P. Davis describes precisely the type of business to business collaboration we worked with in our post, albeit at a much higher level. Mr. Davis describes a truly ubiquitous activity cutting across businesses at all stages of maturity. Examples of this type of collaboration, as Davis demonstrates, can be found all the way from whole sets of companies coordinating product release dates around the target debut of a new smartphone, all the way up to a new jetliner from Boeing or Airbus.

We came to two conclusions as a result of reviewing Jason P. Davis’ article:

  1. His “Synchronicity” is much easier to identify around hardware devices than it is around software applications. Based on our experience, we can say Davis’ “synchronicity” usually occurs around the debut of operating systems, or major platform releases (for example, Enterprise Content Management or “ECM”, or Enterprise Document Management, “EDM”)
  2. Despite the popularity of this activity, we nevertheless hold to our position. Early stage ISVs will do very well to carefully consider whether or not it makes snese to build products based on “synchronicity” before leaping into an effort

Ira Michael Blonder

© IMB Enterprises, Inc. & Ira Michael Blonder, 2013 All Rights Reserved

29
Jul

Collecting Information About Retail Customer Behavior Inside Retail Stores Makes Sense

Posted by | Categories Developing Products | Tagged , ,

Stephanie Clifford and Quentin Hardy authored an article, Attention Shoppers: Store is Tracking Your Cell, which was published on July 15, 2013 in the online edition of The New York Times. We’re interested in this topic, meaning technology to track the behavior of retail customers within a store. As far back as 2002 we had some involvement with ISVs developing solutions for the Radio Frequency Identification (RFID) market. These ISVs were working on very similar technology.

The systems Ms. Clifford and Mr. Hardy describe work within a different computing paradigm: namely WiFi management within a building. By tracking cellphone WiFi usage, ISVs have built methods to compile visit logs for individual customers. We agree with the article authors, the public concern about invasion of privacy issues around the collection of this information is certainly inconsistent with public attitudes about tracking cookies on websites. But there is an important difference. Some website visitor notices about the use of tracking cookies include a warning of a loss of functionality if cookies are not enabled in browsers. Bottom line: “If you visit our site and don’t use cookies, you won’t get the benefit of what we offer”. Perhaps reailers who want to use the technology described in the article should include similar language.

ISVs with technology brick and mortar retailers can use to compile this type of information have a near term opportunity to cash in. There are network and business intelligence components to the technology. We think it will take sometime before retailers can demonstrate relationships between store visits, shelf life for products, and likely buyer behavior. But the starting point, meaning systems to collect the information, appears to be in place.

Of course, there is a side benefit for retailers who choose to implement this technology. They will be able to pinpoint retail customers checking store prices for items against online competitors.

Ira Michael Blonder

© IMB Enterprises, Inc. & Ira Michael Blonder, 2013 All Rights Reserved

25
Jul

Avoid Designing New Technology Products Dependent on Parallel Changes Outside of Your Control

Posted by | Categories Developing Products, Product Marketing | Tagged , ,

On July 10, 2013, Mr. Michael Endler, Associate Editor of Information Week, published an article to the Information Week website: Microsoft Preaches XP Conversion. The problem Mr. Endler describes in his article, amounts to a public relations snafu for Microsoft®.

According to Mr. Endler, approximately 160 million Microsoft Customers for the Windows XP product are stuck on this now obsoleted platform. They can’t migrate up to Windows 8. The hardware they own won’t support the new operating system. PCs and laptops are now out of favor, so consumers have little, if any incentive to spend the money on the new hardware required to run Windows 8. At the same time, the old operating system still works (We, ourselves own a laptop running Windows XP and still use it daily with zero problems).

So what’s the lesson for early stage technology businesses? Don’t design products your customer can only use should he/she buy something from somebody else. This point may seem obvious, but for several product cycles Microsoft implemented the same product strategy. Intel® would introduce a new chip and Microsoft, in turn, would build an operating system designed to exploit the capabilities of the new chip’s kernel. But here’s the catch: Microsoft had no responsibility for the new hardware. From an accounting perspective the new operating system software was very profitable. As well, smartphones, tablets and thin client computers (like Google Chromebook) had not yet hit the market. So the serious vulnerability this product development strategy exposed was, apparently, not a major point of concern for Windows product management.

Now, of course, consumer tastes for computing hardware have changed dramatically. Microsoft is stuck with millions of customers who can only become more dissatisfied, as time goes by, as support for Windows XP falls away. With this conundrum in the spotlight, it shouldn’t be difficult to understand why the Surface initiative was an important step forward for Microsoft as it attempted to correct the product design methodology of the past.

Ira Michael Blonder

© IMB Enterprises, Inc. & Ira Michael Blonder, 2013 All Rights Reserved