Anticipatory systems in some form have been used for some time, and one of the best examples is in the systems management field.  Software monitors servers, networks and loads, identifies conditions that might require action (for example predictive disk failure), and alerts the server managers that such a problem has occurred.

The wide penetration of smart phones has expanded this opportunity immensely and true anticipatory systems are beginning to emerge.  The best example to date is Google Now – available on most Android phones.  Using locational information and search history, Google Now can show a user information relevant to them at a given point in time, such as the weather, calendar related events, travel time to or from work, current stock quotes and local shopping locations.

We suggest that this is just the beginning.  Let’s take a scenario.  You have a flight booked to leave your home airport at 2pm.  Your phone knows this from a calendar entry.  It monitors travel time to the airport, and alerts you when to leave and suggests best routes as you travel.  In the meanwhile, it checks you in to your flight, and prepares your boarding information as you approach the airport.  When you arrive, it suggests where to park and advises you which gate to go to and how long the security lines are.  It also suggest where to buy a snack before you board the plane.

None of this is science fiction, and most elements of this story are available right now in bits and pieces.  Integrating these disparate information sources will be a significant new opportunity within mobile software.

Are scenarios like the above a bit creepy? No problem, you can turn it all off and miss your flight!

For the mathematically minded, a fascinating book on the subject is: “Anticipatory Systems:  Philosophical, Mathematical, and Methodological Foundations” by Robert Rosen.

https://www.facebook.com/pages/Viscount-Innovations-Incorprated/1416055991943748

Or you can click on the FB icon on our website banner above.

Some believe that universities have difficulty bringing Dark IP projects to commercialization, even if those universities have commercialization offices to do so.  These offices, some think, are too bureaucratic, too underfunded and too overwhelmed with volume to do an adequate job.  This may be so, but only some academics have a desire to be entrepreneurs, and many are satisfied with patent filings to show on their resumes.  Are innovative ideas lost this way – probably!

On the other hand, as a mitigating factor, funding sources will always urge the universities to exploit to the best of their abilities, the research that comes from funded projects.

We have less concern about the future of rogue projects in a commercial business.  Most modern, progressive companies have figured out a process to deal with these types of issues – a good example is the Emerging Business Opportunities (EBO) Program at IBM.

Both funding agencies and universities could set aside funds to mimic the IBM EBO process, or some derivative of it, and thus bring Dark IP to the light of day.

More plainly stated, most web site owners are able to use products such as Google Analytics to determine the source of web traffic – for example if it was referred from Facebook, LinkedIn or other social networking site. It is assumed that all other sources of traffic were more or less direct, that is, someone knew the correct URL and typed in the correct URL directly.

The problem is that many of these “other sources” are not truly where the website URL was directly typed in, but instead is a link referral through email, texting or other non-trackable source. Many web masters claim that between 25 and 50 percent of their web traffic cannot be tracked to its source, and most believe that the situation will become worse not better.

Furthermore, although not mentioned extensively elsewhere, data collected for sentiment and web opinion analysis is never sourced from dark social sources – and a potentially critical amount of information is never analyzed. No one seems to be able to measure the magnitude of this problem.

The message is to be wary of conclusions drawn solely from standard analytics and sentiment analysis. It may be showing only part of the picture and may be biased along many dimensions.

In no particular order, here are “Robert’s Rules of Software Pricing – But You’ve Heard Them All Before”.  This is extracted from a discussion at the York Technology Association led by Robert Wolfe.

1. Increase prices with major upgrades only.
2. Preferential prices are a slippery slope.
3. Creating an innovative pricing model requires deep pockets.
4. Free is always tough to convert to paid.
5. Always seek scale economies.
6. Gain margin from efficiency increases, not from price increases.
7. Give salespeople rules and reward them for holding fast to the rules.
8. Trade price for contract length (recurring revenue).
9. Throw-ins cost more than planned.
10. Never forget good contracts.
11. Price complexity leads to failure.
12. Make certain to factor in the cost of development.
13. A software price war always has a loser.
14. Don’t charge for experiments, the customer will come back for more and pay later.
15. No such thing as a cash cow customer – but delighted customers can be depended on.
16. Customers should understand their ROI.
17. Price to value.
18. Always, always, take the long view.

We’re sure you have more suggestions – please comment.  If you’d like advice on pricing please call 1-888-277-1174.

We’ve learned that software valuation has two perspectives – the buyer and seller, and without some form of alignment, there will be no satisfactory transaction.

Please take a look at the attached PDF summary of our views and a few examples.  The document was originally part of a presentation to technology professionals.  But before that, here’s an extract, including …

“Robert’s Rules of Software Valuation – But You Heard Them All Before”

1. The last transaction sets the value.
2. Investors with ready cash set the value.
3. Competition is a good thing – validates the market.
4. Customer lists have no long term value.
5. Mature technology is a declining asset.
6. The bleeding edge needs deep pockets to realize value
7. Strategic value is huge.
8. Patents have value if you can defend them.
9. No one likes “hockey stick” forecasts.
10. Human capital has value if it can be retained.
11. Never rely only on a forecast and DCF to set value
12. Comparables are interesting but can’t be used alone
13. Forecasts set by sales people are worrisome
14. Exploitable tax credits are worth about 10% of book
15. Good will has no value
16. Use marketing $ to get customers – don’t buy them
17. Lines of code can’t be used for valuation
18. Sunk development costs to date measure value
19. Always try to leave debt behind
20. Technology without a business has low value

There are likely many more rules, and in some cases our readers will likely disagree with our “Rules”.  Here’s the complete PDF…

Valuing Software Companies and Software Assets 2013

On the last page – our strongest advice…leave software valuation to the experts, as doing it yourself leads to problems.

Questions?  Call us at 1-888-277-1174

Take a look at the related materials below in the “Around the Web” tab to read more.

1. There is a common competitor that has to be surpassed.  Here companies cooperate to best the common competitor, but compete amongst themselves in other ways, such as service levels, excellence, etc.
2. A goal cannot be achieved alone, but can in cooperation with others.  This may be where some form of industry standard is needed (e.g. USB), and being proprietary makes no sense.
3. A competitor has a feature your customers want. Instead of investing directly in that feature, limited cooperation may be best.

Co-opetition requires maturity and a clear sense of purpose, but when executed well, it reaps rewards and achieves higher customer satisfaction.

Two examples…

• Apple cooperates with Yahoo for content on their phones – both worry about supremacy by Google.
• Apple cooperates with Samsung on hardware issues – they each have items the other requires.

Please see some links below, including a lengthy academic set of charts that show how co-opetition is really just a form of traditional game theory.