The Rochester Startup Ecosystem — An Embarrassment of Riches?

Can too much of an ecosystem be a bad thing?  Or to be less gnomic about it, over the last decade Rochester’s developed an enormously elaborated network of resources and groups supporting entrepreneurship and a startup culture, which you’d think is phenomenal — but is so much, in this case, too much?

I asked myself this question after attending the last RocGrowth meeting on March 15th, which I was incredibly impressed by — really interesting presentations, really involved audience, a meetup that could as easily have been San Diego or Boston or anywhere else.  I’ve lived in Rochester for 11 years now and I know people are sometimes negative about the opportunities, but it was hard to walk away from this meeting feeling that naysayer attitude can possibly be correct.

But could the opposite actually be true, that there’s too much going on here now, too many events encouraging a startup culture, entrepreneurship, rebirth of the city and the region?  That might seem counterintuitive, but the more events there are, the more people have to  pick through these events to separate the wheat from the chaff.  Unless, of course, you assume it’s all invaluable stuff, which I’d argue on first principles can’t be the case, although of course I’d love to be proved wrong on that point.

I don’t have a strident answer to this question, my feeling is this signal-to-noise problem is generally a good one to have, as long as people are honest about it, and as long as there’s continual striving to improve the signal and diminish the noise.

I think it’s a sign of our community’s maturity that we can assert ever more discerning tastes on the part of what we should certainly call the “customers” for these events, this training, these opportunities.  If a set of events isn’t useful, that fact needs to get out as fast as possible so that the event series can evolve or die.  The alternative is a little bit of signal and a lot of noise that entrepreneurs of all shapes and sizes will fritter away their time on.  I’ve no doubt that there was a time when all events were good by virtue of there being more of them; but the situation’s now (happily!) considerably evolved.

Call this the “Willful Reimposition of Disbelief Movement” if you like, or, more euphoniously, the “Movement of Artful Disbelievers,” “MAD.”  A movement where we as a community recognize we’re now far enough along to have short attention for lesser events, and are willing to be direct enough to say so, although certainly with thought (artfulness) backing up the criticisms.  After all, any startup — any enterprise whatsoever? — has to be willing to change, we might as well propagate the concept to startup types and also to startup/entrepreneurship community events.

I’ll close by adding that although I consider myself a fully MAD participant, I’m not writing this with any particular group a target for my MADness.  I simply think it’s imperative we demand the most we can both from ourselves and from our communal resources.

Get MAD.  The ecosystem will thank you for it.

Lean Startups & Big Data & Facebook & Ovicap.org — Part 1

I’ve previously written about the sheep-goat dating website, ovicap.org, which I use as the paradigm example of a cyberspace application, you know, set up a website that connects A to B, gives free access to A and B, and makes money by selling ad space and A and B’s data to anyone with money to pay.

This has always been an “exciting” model, by which I mean enormously profitable and dubious at the same time.  There’s certainly more than a little willful suspension of disbelief behind it, it requires that the user happily give away enormous amounts of personal data on the whisker-thin illusion that the honest and upstanding proprietors of the website (and harvesters of the data) will … treasure it.

Yes, well, treasure it they do, but likely mostly in the direct sense of for the value it provides as valuable data for sale, not the kind of treasure that pirates would protect in a chest or a lockbox or what have you.

***

Charles Ellms — The Pirates Own Book (1837).  See Public Domain Review — Piracy At The Old Bailey

This could easily become a tirade on how we ought know better than to assume data won’t be skillfully aggregated and bundled and sold (or stolen) by the malicious vagabonds of the internet who are masquerading as high-tech robinhoods … but I’m just not in the mood for this sort of tirade.

I also don’t want to make this into a discourse on whatever underlying structures in our brains make us indifferent to the idea that we can be tracked for profit — in my case, the wetware anomaly is that I don’t believe anyone would care to do so simply because my life strikes me as really boring, and I can’t fathom someone else finding the interest to surveil me or, for that matter, anyone wanting to buy that surveillance data.

But then again machines aren’t people, they’ll do whatever they’re programmed to do, including collecting and collating information on boring people like me.   And people can themselves be similarly motivated when the ends are exceptionally high value, witness the Russian meddling and Cambridge Analytica and so on.

***

Charles Ellms — The Pirates Own Book (1837) — “Gow Killing the Captain.”  See Project Gutenberg — The Pirates Own Book

What’s most interesting to me about the recent rediscovery of massive data harvesting on A-connecting-B internet sites is the larger question of how to gather and use data in a safer and more responsible way, and not what the immediate repercussions of these sudden revelations may be, e.g., the wholesale slaughter of the purveyors of these websites by that particularly horrible of horribles — “regulatory overreach.”

This strikes me as a three-part analysis, which I want to briefly lay out because I think it will likely serve as a framework for later posts, particularly posts on the question of whether data harvesting in a safe and ethical way — “protected” data harvesting — can be applied to startups and entrepreneurship, where companies succeed or fail depending upon the flow of data between the team members and, therefore, the need for better control/flow of data is particularly acute.

***

 

IBM Poster, “See Everything With Punch Cards” — See, e.g., “IBM And Its Subsidiaries And The Holocaust” (AHRP see also Jewish Virtual Library — The Nazi Party: IBM & “Death’s Calculator”).

As to Part I, as a threshold question we need to decide whether to accept or reject the idea that massive data harvesting is a good thing, not necessarily in general, but certainly for particularized ends.  This isn’t a trivial point, because the history of massive data gathering about people isn’t a happy one, and these bad facts can’t be dismissed as something from purely antediluvian times.  See, for example, the interesting (!) history of IBM’s involvement with Hitler’s final solution, where IBM provided the punch card machines and system for gathering the eugenic data on the human populations under Germany’s dominion, and much else besides — note this history intimately (and ironically?) involves IBM’s chief Thomas Watson, whose name is now given to IBM’s major product, the “Watson” AI system.  See Wikipedia — IBM And The Holocaust.

Now on the other hand, data gathering can have very useful purposes, a point that’s emphasized when trying to deal with pandemics or solving human wants and so on.  In 2002 I wrote an article arguing that DNA testing could be used for the admirable purpose of establishing identity — “ethnicity” but without the negative eugenic trappings that latter term invokes.  See Journal of Biolaw and Business — Bioethics and the commodification of biotechnology.  At the time the reviewers forced me to add a large number of declamatory statements about the dangers of such testing, but of course now you can’t go an hour without seeing ads for this kind of datagathering on the Teevee.  In other words, times change and some datagathering turns out to be more benign than we thought (although see NY Post — Schumer Warns About DNA Testing and other, far more erudite citations).

The conclusion we can draw is that datagathering of people data is a balancing act, one that weighs positive results again the loss of privacy and abuse of the data.  Hardly a surprising statement, but again it’s rather revelatory in light of advances in computers and AI and non-regulation of A-connecting-B websites (Facebook, Google, etc.), all of which have enabled data collection far beyond what we imagined when we first embraced the internet.  Give it the moniker “extreme data-gathering” if you like.

***

Given this balancing act, consider the Part II question to be: how do we ensure appropriate privacy?  Easy question to ask, hard question to resolve, and I’m certainly not claiming superhuman abilities in this regard.

That said, here’s a three-part division of possibilities: 1) rely on regulatory solutions; 2) rely on technology solutions; and, 3) stop harvesting data.

Since this post is already rather long, I’ll defer the discussion of these alternatives to a separate upcoming discussion.

An Introduction To “Teamspace”

In previous posts I discussed the MVP-VOC-pivot cycle that the lean-startups model uses, a model in which 1) you assume you don’t understand what customers want, but that 2) you can get to that understanding by implementing a “Minimum Viable Product” (“MVP”) that 3)  you then test against the Voice-of-Customer (“VOC”) and 4) change (pivot) as a result, with 5) this process repeated until you obtain a good product-customer fit.

Before I go on to more discussions about products and markets, I want to take a minute to point out that this MVP-VOC-pivot cycle is applicable not just to products but also to teams, and that just as there’s a pivotspace for products, there’s also one for teams — call it “teamspace.”

Consider the two-member team of co-equals in the illustration (see Spider Monkeys), the smallest team configuration there is.  If the operant theory is that a startup doesn’t understand its product until it tests a minimal implementation (MVP) against the market, why not apply the same theory to the team configuration, and assume there will be a first “Minimum Viable Team” (“MVT”) that will succeed more or less well and, as a result, will be quickly reconfigured to a different MVT, say MVT2, and so on.

***

There’s a reason I’m introducing this concept, and a very particular reason I’m introducing it early — startups succeed or fail based mostly on the team and how well it executes, and not on the technology, no matter how cool.  And therefore it’s critical to pay at least as much attention to the evolution of the team as it pivots through teamspace as it is to track how a product evolves through product pivotspace.

Consider the “Business Model Canvas” (“BMC”) depiction of the lean-startups process:

This is the standard illustration you’ll come across for the lean-startups methodology, the upper right corner shows the core product-market component (“Value Propositions” and “Customer Segments” respectively) along with the ties that bind the product to the customer — “Customer Relationships” and “Channels.”

You’ll note that, despite being the canonical illustration of the lean-startups trifecta of MVP-VOC-pivot, there’s no good way to show the sequence of iterations through pivotspace.  Instead there’s an emphasis on the other things that tie in to the development of the product-market fit, specifically the resources required to make product (“Key Partners,” “Key Activities,” “Key Resources”), as well as money inputs and outputs (“Cost Structure” and “Revenue Streams”).  These resources certainly are critical to a business and are therefore worth teasing out, but again the illustration doesn’t allow for an exploration of the MVP-VOC-pivot iteration cycle for product.

I don’t want to create a strawman here, certainly other versions of the BMC attempt to solve the this problem, although as I’ll discuss in a future post these alternate formats are still quite inadequate to the task.  But regardless of the ability of the BMC diagram to inform a product development path through pivotspace, you can see that the BMC provides absolutely no framework for understanding the teamspace, or the path of the team as it evolves from Minimally Viable Team 1 to MVT2 to MVT3 and so on to a deployed team that matches market pull just as the product must match market pull.

***

I don’t know why the lean-startups methodology doesn’t provide an explicit exploration of the human side of product iteration.  Based on my own experiences as a business mentor for both the National “iCorps” lean-startups program (in Washington, DC) and at the regional New York City and environs “NYCRIN” program, I’d say the problem is at least partly that it’s like trying to build a new design of a plane at the same time as the plane under construction is going down a runway also being built, with the plane under the instructions of a control tower being staffed.  Oh, and the plane’s running on tanks of gas that are being filled.  And it’s on fire.

In other words, when a company is trying to get started there are more than enough problems to deal with, and certainly the lack of the product matching the market is a key one that rightly gets attention.  But you can’t ignore the evolution of the team, and the lean-startups model is easily adapted to a team iteration cycle of MVT-VOC-pivot, a cycle which can be explored in every bit as productive a way as is the similar product cycle.  This exploration of teamspace may start with a spider monkey dynamic duo, but after repeated pivots and tests of the refigured teams against the market a trio of monkeys in a hierarchical org chart structure may result, with each adapted (via hand size) for different tasks in the developing organization.  (Image at Free Clipart)

More on this in future posts.

Defining The Technology’s Outer Limits

Of course you remember my previous example of a cyberspace product — the sheep-goat dating website ovicap.org?  As you’ll recall, cyberspace applications have a low barrier to entry as compared to those that have to produce real-world results, i.e., “meatspace” products, and this fact makes connecting-A-to-B -and-somehow-monetizing-the-connection websites such as the sheep-goat dating website altogether too common.

You’ll also recall that I described meatspace as being difficult for its problems of prying something that works from the breast of Nature, although this balances against the appeal of the high-tech requirements that usually underly something in meatspace.  I gave no graphic example before, I now direct you to the “cat piano” shown above (Imaginary Instruments — Cat Piano), which is about as close to a “red in tooth and claw” implementation as it gets, although I admit the cats in the illustration look pretty placid.

A story bifurcates depending on whether it’s of cyberspace or meatspace; regardless, for either domain a story falls within an ambit of possible alternative embodiments — a pivot landscape — and can and should be developed with a very clear idea of what falls within the ambit of that pivot landscape and what falls outside it.

In other words you have to define the outer limits of your technology, which means knowing not just 1) what you can do and 2) what you might do, but also very definitely 3) what you absolutely cannot do.

***

In order to better explain this idea, let me start with a brief summary of the currently favored “lean-startups” methodology.  There are an enormous number of on-line resources that explain the lean-startups model, my brief summary is that:

  1. A typical (non-startup) business can be modeled by way of already-existing comps, for example the success of a new pizza restaurant can be estimated by looking at the number of other pizza places in the area, diner population, costs of space, known costs of making pizzas, labor costs, etc.
  2. A “startup” is difficult or impossible to  model in the same way since it’s producing a product that’s “new,” and therefore has no easily available comps.
  3. Startups often try to solve this problem by creating a feature-heavy product, particularly when the startup is making a high-tech product that’s easily laden down with engineering-based features.  This feature-bloat is, at best, bad, and most likely lethal, because it spends resources to develop a product that the market doesn’t want.
  4. The solution for a startup is therefore to implement a “Minimum Viable Product” (“MVP”) as quickly as possible and test it against the market Voice-of-Customer (“VOC”) to see if the MVP meets market pull.  And if it doesn’t, iterate the MVP to a different configuration and test against the market again.  And so on and so forth until the series of iterations (“pivots”) leads to a good product-market fit, i.e., the MVP-VOC-pivot cycle defined in the lean-startups model.

There are a lot of things to like about this model, foremost the idea that you “fail” early and fast and small, and that each “failure” is really just a mismatch to the market which can be pivoted by revamping the MVP and retesting until a market match is identified.  In other words, even for a startup, success is obtainable.  As a result, the lean-startups Standard-Operating-Procedure (“SOP”) focuses heavily on small ideas (MVPs) tested against lots of customers.

***

Thing is, the lean-startups SOP pays little if any attention to 1) the ability to pivot and 2) the extent of possible pivots.  In other words, if real-world reaction to an MVP is to a different product that’s too hard for the company to make because it lacks the resources, the identification of this potential pivot isn’t useful.  And, worse, if the pivot is to a product that the company cannot make under basically any circumstances, the MVP-VOC-pivot idea is really rather worthless, at least without more.

My standard example is a company that makes nuclear weapons — call it “Nukes-R-Us” — that’s looking to expand its business because the market’s dropped off for thermonuclear devices.  Assume this is some sort of startup situation, so apply the MVP-VOC-pivot cycle.  And let’s say that what immediately becomes apparent is that there’s a huge market pull for children’s toys … should the company pivot to making children’s toys?

No, of course not, even if the demand is vast, Nukes-R-Us can’t go from a core competency of making bombs to making Elmos or even plushy toy robots.  And by “can’t” I don’t just mean “we don’t have the resources to pivot to that model,” I mean it’s so insanely not within Nukes-R-Us’s competency to go from nukes to Elmos that it’s flat out not possible, not even if you roll in something catchy like “Nukes-R-Us-Bitcoin-Toy-Company” to attract lots of investment dollars (you know, of course, that everything’s better with bitcoin).

On the other hand, within the landscape of possible pivots — the landscape that definitively does not include pivots like the nukes-to-toys one — Nukes-R-Us might actually be able to pivot to fun rides that involve reentry into the atmosphere on warheads without the plutonium or the bang, e.g., as shown in the lovely graphic to the left (Riding On Nuclear Bombs).  It wouldn’t be a straight shot, but presumably Nukes-R-Us is good at making the bomb casing and fins and guidance systems in addition to the bangy part inside, so the pivot is at least possible, although admittedly not altogether fundable.

***

The above discussion captures the idea that the lean-startups MVP-VOC-pivot model isn’t infinitely malleable; instead, pivots are constrained both in terms of 1) getting from one MVP to another in pivot range, and also in terms of 2) the impossibility of access to whole areas of MVPs altogether — the ability and extent parameters I referred to above.

I haven’t quite decided what graphic best describes the situation, one possibility is the figure to the left, which shows the pivot landscape as a series of obtainable “islands of opportunity” defining MVPs, with these islands rising up out of a sea of exclusion and surrounded by a crimson wall outside of which there are no MVP pivot points at all, just monsters.  In this graphic each of the colored columns represents a particular defined island of opportunity with its own MVP, so that, for example, MVP1 might be the green column, which on testing against the market led to a pivot to MVP2, which is red, and then to MVP3 (purple) and so on.  Thus the graphic can be used to show an actual trajectory of MVP discovery, in the example from green to red to purple MVPs.

Alternatively, I’m tempted to provide the representation to the right, where these MVP-containing islands of opportunity are largely shrouded in mist, indicating that the landscape of possibilities (alternate MVPs) isn’t particularly clear.  This is a better parallel to the real-world situation, and certainly captures the key concepts that 1) a company’s technology encompasses a set of distinct (and disjoint) MVPs, 2) hopping/pivoting from one MVP to another can be easier or harder depending on their separation in the landscape, 3) some of the MVPs are easier to define than are others, and 4) the set of MVPs isn’t infinite in extent across the landscape — outside the islands is just water, and that water is deep and dark and not explorable.  Again, Nukes-R-Us might see that there’s money in toys, but it’s not likely they’ll ever be able to pivot to that kind of MVP, they’re stuck with the pivot landscape that their business experiences and connections and brick and mortar and cyber capacities dictates.

***

To summarize this post, startups are hard to model because they do “new” things that are without comps, and the lean-startups methodology addresses this by an iterated pivot model of MVP-VOC-pivot repeating itself as the company titrates its product towards what the market wants.

This is a legitimate framework with many advantages.  However it fails to recognize that 1) pivots aren’t automatically obtainable, they occur along a path of possibility through a pivot landscape, and 2) that the pivot landscape is finite in extent, you can’t pivot to models that are (to quote “The Princess Bride”) “inconceivable.”

I’ll pursue a framework for analyzing pivot space to understand the potential pivot points (“islands of opportunity” if you will), trajectories between them, and explicitly defining what the company cannot do, and not just what it can.

Storytelling — Cyberspace & Meatspace

In my previous post I talked about startups in cyberspace and startups in meatspace, and how each domain brings its own advantages and its own difficulties.  To briefly recap, cyberspace is usually very cheap in terms of deployment and in the best cases offers such an incredible Return on Investment (“ROI”) that almost any business model can get funding, no matter how irrational the business case.  I used the sheep-goat dating website as an example.

Meatspace, on the other hand, is not forgiving of mere ideas — a tangible world product either works or it doesn’t.  High tech certainly sells, but the long path to success and high likelihood of failure for many meatspace products (particularly in the medical space) creates real reluctance for money sources to invest.

Given the above, while a business aiming to play in either of these spaces must offer a compelling story, the form of that story will differ depending on the intended regime.  Perhaps an obvious statement but, in my extensive experience, not one that small companies seem to understand.

***

Cyberspace Storytelling

I come from a meatspace background — B.S., in Biochemistry, Ph.D. in Biology/Molecular Biology and several esoteric postdocs.  That said, I have plenty of respect for cyberspace businesses, and even though I poke at them quite a bit, I’d be the first to say that success in this domain is anything but straightforward.

As I’ve already said, barriers to entry in cyberspace tend to be much lower than in meatspace, therefore storytelling for cyberspace products usually has particular foci that hammer out brute-force superiority versus competitors.  Website design no longer provides this, nor does the sudden identification of an unmet need ‘twixt two hitherto unconnected groups (the sheep-goat dating website example).  So storytelling for cyberapps pretty regularly emphasizes quick market capture, rapid expansion of customer base, and direct and secondary tie-ins that keep that base on the platform and revenues flowing in from someone.  You know, the Facebook model, billions of users, lots of captured eyeballs via Russian bot spread salacious stories, tie-ins to and monetizing of … whatever Facebook is tying in to and monetizing these days.

There are two lessons here: 1) you have to tell a strong story of how your model has built-in brute-force power and 2) you have to make sure you circle back to this story as it plays in terms of a barriers-to-competition component.  People may be more willing to bet on cyber because of the potentially incredible ROIs, but they still want some real comfort zone as to how you can beat out the competition, especially since cyber’s easy to enter.

***

Meatspace Storytelling

Meatspace products usually are easy to sell in terms of barriers-to-entry, certainly high-tech real-world applications present as being resource- and skilled-worker-intensive and, consequently, not easily subject to competition.  On the other hand, meatspace is hard, and practitioners tend be too in love with their technologies and not focused enough on the product that’s just viable enough to get the requisite customer base — the Minimum Viable Product (“MVP”) as it’s called.  So there’s a lot of skepticism towards ideas in this domain as to whether they’re really thought out in terms of actual market and correct configuration.

Regarding market, these days it seems very hard to get a meatspace company funded without significant Voice-of-Customer (“VOC”) data, and in future posts I’ll talk a lot more about why this is a great idea in theory but often suspect in practice, especially if it’s a mechanical implementation of the “Lean Startups” model of “Just talk to 100 people” idea.  The quick preview is that there are customers and then there are Customers, and a company has to be careful to distinguish between those they simply report because they talked to them (“customers”) and those they talked to who really fall into the group of potential buyers or instigators of buying (“Customers“).  Put a 10 year old boy (or, these days, girl) in the first category when presented with an actual killer robot product (plasma cannons, AR15 attachment, etc.), put the parents in the second category.

“Correct configuration” is important, in that there’s a two stage process that is critical in meatspace: 1) make sure your product has real appeal for a large enough customer base and 2) make sure your product isn’t so laden with unneeded/unwanted features that it’ll never make it to market (technical problems in implementation) or will cost too much for people to buy it.  The first factor is essentially a restatement of the market requirement, but from the point of view of the product configuration, the second is a manifestation of the love for engineers engaging in too much engineering.

***

Summary

To give a quick summary, there are cyberproducts and there are meatspace products, and for that matter there are hybrids of the two.  All have storytelling requirements, but the storytelling for each has different emphases and different audience requirements.

Never forget that last bit, it’s not what you think is cool, it’s what plays to your audience.  This recognition isn’t everything — audiences can be 100% idiot-containing, and any business has to balance what people want to hear and what they need to hear.  But if it isn’t everything … well, it’s still an awful lot.

Meatspace & Cyberspace & The Sheep-Goat Dating Website

I draw a distinction between startups that create tangible-world “meatspace” products and those creating cyberproducts such as the (hopefully hypothetical) sheep-goat dating website I announce in the graphic above.

In brief, meatspace is a hard environment for innovation, nature red in tooth and claw not being keen on giving up her secrets, nor for that matter are capital sources eager to invest in the apparently infinite sinkhole of money involved in tearing those secrets away from nature’s breast.

Cyberspace products, are simpler, inasmuch as they typically fall into a “connect group A with group B and monetize the connection” approach.  Consider the sheep-goat dating website, which I’ll pitch with the following (straightforward?) business model:

  1. Sheep and goats have a secret desire to date one another but there’s no platform to allow for the expression of their illicit love, a statement we’ve validated with extensive (100) contacts to gather Voice-of-Customer (“VOC”) data in barnyards across the country;
  2.  Ovicap.org will offer a platform for private connections between these cloven-hoofed animals and thereby meet this enormous need;
  3. Ovicap.org will operate on a freemium model, with basic membership free but a cloven-hoof-adapted keyboard on sale for premium members;
  4. Ovicap.org will derive revenues from ads sold to its partners for display on the website to the member sheep and goats, and also from datamining the predilections of the sheep and goats for sale to breeders and political/influence groups in rural areas; and,
  5. Ovicap.org’s model is easily and rapidly expandable to address the untapped desires of other barnyard animals, which we will exploit either directly or via licensing/franchising partners.

There you go, sound familiar?  The thing is, it’s not as tongue in cheek as you might suppose, after all the barrier to entry for a website is ungodly low and, if it hits, it can hit with a 100x or higher return on investment.  And so the internet is littered with platforms that attempt to exploit this “A to B = money” idea, some more, some less successful in their attempts.

***

Meatspace, on the other hand, is ultimately more than an in-vogue business model, since at some point the thing being developed has to do more than promise to work — instead, it actually has to work.  NextGen battery technology that stores more energy in a small package is instantly saleable in that the technology’s well-known to be needed, desired, and instantly money-making if obtained.  But there’s a back hole lurking behind that “if obtained” statement, because the technology is one that’s really hard to get working, nature red in tooth and claw again busily at work.

***

Having drawn the dichotomy I want to give several lessons that derive from it which are useful in moving either model forward.

First, there’s appeal to both stories, but they’re fundamentally different.  Cyber solutions can be relatively low-tech, more rapidly tested and, if the minimum viable product (“MVP”) fails, quickly and efficiently pivoted to something that works/sells better.  Meatspace products are hard to present as agile, but on the other hand high-tech can still be highly alluring to investors — “sexy” being the most-applied word.  The problem is that sexy in theory isn’t sexy-in-the-bare, the situation that transpires when the vision meets the reality of the complications underlying the technology.

Second, whereas the cyberspace story will likely focus more on quick capture of market and metastasis to a huge customer base, in meatspace the questions are uncomfortably focused on how much it will really cost to obtain the technology as well as the balance of whether estimations of demand and price really make that path-forward reasonable.

Third, each domain is populated with founders with characteristic “features,” which is to say character flaws that need to be managed and directed.  In cyberspace it’s easy to have a visionary whose insights mutate by the minute — again a cyber platform is nothing if not mutable.  The problem is implementing some real focus on testing possible iterations rather than just iterating because it’s so easy to do so.  On the other hand, in meatspace the usual problem is the blinding love by the technologists for the technology.  While this is critical for forward motion, it leads to a tin ear to what the market actually wants as opposed to what the technologist thinks it wants

***

The conclusion I’ve come to over time is that both meatspace and cyberspace products and companies have a place, and each model can, at best, help inform the other.

More on that in future posts.