Foster Ecologies

March 4, 2015

So here was this tweet today

retweeted, 

If you want to go fast, go alone. To go far, go together – African proverb

Out on Twitter over the last week, I dropped a tweet or two about product ecologies after watching a YouTube on the human biome. Actually, there were several human biomes that we migrate across and live within or under over out lifetime. Products do a similar thing.

Your whole product vendors have third-party developer programs that operate for the vendor’s benefit. These programs are multisided markets, so the third-party developers get something as well. Multisided markets can serve the carrier vendors with their API expanding the original vendor’s functionality, the carried vendors with their models, and another carried vendors data–layers, many layers all on the same roadmap, all moving at different speeds, all moving in different directions–going together. Everyone in this tech ecology gets functionality at some level, but they also get prospects. They get channel. Channel is hard.

Channel is hard because channel participants are there for their own reasons. They have their own motivations. They have to be led just like your matrix team members. They serve and monetize around a population. You’re participation in their channel might demonstrate objectivity to the population they serve. Sales in that case might be accidental.

So we have lots of interests to serve beyond prospects, economic buyers, and users, beyond our monetizations, and beyond the interests of our internal interest groups. Oh, the messiness of going together.

Alone, we will not create a category. I know. Most of us are not trying to create a category. Most of us are not trying to build a business around a discontinuous innovation. We have far to go, so we have to go together. If you tried to go it alone, you’d be facing antitrust issues. Competitors help overcome these issues. No negation tends to go a long way to keeping competition respectful. You can’t have more than 74% of the market, and you would be lucky to get that 74% from a market power allocation. These days it’s market share as an outcome of ones promo spend and VC funding, which doesn’t get anywhere near 74% and isn’t lasting like that 74%. Early and late tech adoption businesses and economics are vastly different.

Going together reminded me of when my employer got a supercomputer gratis. That hardware vendor wanted us to support their machines. Our application generated code. Compiles took a while, so now we could support a new value proposition, compiling our customer’s code for them using that supercomputer. Long ago, I know.

In a later company, the computations moved, so we could move them to machines that were faster, or slower. You could play with an algorithmic ecology. You could run several heuristics to get there ahead of the more accurate algorithms with the algorithm with the best accuracy coming in last, at last. The sort of thing we do with Monte Carlo simulations running in our edges of the unknown later substituting knowns as we capture them.  Running fast, but going far together.

Fostering ecologies gets us down the road together. Foster an ecology today.

Comments?

Limit Cycles

February 21, 2015

I’m reading Colin Adams’ Zombie & Calculus. Zombies are not an interest of mine. There are no Zombie Rescue stickers on my car. I’ve never seen a Zombie movie and won’t. All right, I’ve escaped the Zombies. My differential game.

In the book the protagonists, those who have not yet been caught by the Zombies, and the antagonists, the Zombies engage in differential games of capture and pursuit. A differential game is a game played between two or more players where each player has their own differential equation. A differential equation expresses a rate like iterations per year. Some design considerations might involve rates like how fast will we drive away our geeks vs.how fast will we attract consumers. Or, bringing it back to capture and pursuit, what can we do about that fast follower?

In the book, the Zombies, playing these games, eventually caught almost everyone. Well, eventually caught up with almost everyone is more like it. Almost? Well, the author lived to tell the tail. Meanwhile back in the games, some of the protagonists were able to see each individual’s attempt to stay away from the Zombies. They saw every experiment. In one of the experiments, the protagonist took a circular path. The Zombies kept their eyes on the runner. The Zombies ran in a circle, so they could keep their eyes on the runner. The Zombies kept moving, but could never get closer to the runner. The runner was faster; the Zombies, slower. The ratio of their speeds determined how far the runner’s circle was from the Zombies’ circle. The runner circle is the limit cycle. Cycles like in trigonometry class where we spent time going round and round. Not cycles like those in The Lincoln Lawyer. Nobody was spiraling. Nope, just circles. So, lets look at a limit cycle.

Limit Cycle 01

The faster person, the red dot, runs on the black circle, the outer circle, the limit cycle. The slower person, the blue dot, runs on the gray circle, the inner circle. The blue arrow illustrates the speed of the slower person. The blue arrow is a vector. Enough of that. The slower person keeps the faster person in sight along the thin blue line, the tangent line. Stop that. Oh, another differential game. Colin Adams, the author didn’t throw down a theorem to define the limit cycle. No, he evaded, the proof-based mathematics, he had his own differential game going. He was pursuing an audience that wouldn’t stand for that.

In the next figure we’ll illustrate what happens when the slower person speeds up or slows down.

Limit Cycle 02

The faster person, the red dot is still on the black circle. At the top, the second person has sped up, which made their circle bigger and closer to the limit cycle. In the middle, the second person has slowed down, which made their circle smaller and more distant from the limit cycle. The blue circle is just there to remind us that there are larger scopes even for the larger player. Ultimately, a limit cycle comes with a category. The market leader as determined by market power sells more, has more customers, more money, and more people than anyone else. If you compete with this company you won’t exceed their limit cycle until they bail out of the category. That’s something they wouldn’t do if they saw the point in staying behind.

And, yes, nobody competes for market power these days. Here in the late main street/consumer phase of the technology adoption lifecycle, its all about promo spend and the myth that you can beat the limit cycle. Las Vegas will take that bet.

But, just for grins, lets say your pursuer finally managed to match your speed, what happens next?

Limit Cycle 03

Once you’re pursuer is as fast as you are, they won’t be inside the circle looking at you. They will realize that they still can’t catch you. They’ll stumble on the Wayne Gretzky quote about being where the puck is going, instead of where it was just now. Well, your staff saw the day when a chunk of their offer that that this pursuer competes on would commoditize, and they made sure that they had some discontinuous technological innovation that everyone could ride for the next twenty years. They put a real option on the circumference of the current limit cycle, an unweighted control point ready to bare some weight.

Limit Cycle 04

So your pursuer was surprised–“Oops,” but they keep trying to catch you. Unfortunately a miracle happens.

Limit Cycle 05

They end up inside your new limit cycle. Your pursuer can’t be faster than you, so being slower, the parallelogram flips rotating them inside your new limit cycle. An odd thing happens though. The center of their cycle is not concurrent, is not the same, as the center of your cycle. The more knowledge it took to create your new offering, the more learning they will have to do. They will be elliptical, not shown, until their process maturity has them following you again without additional learning. Mean while, they dream of the day they own the limit cycle, aka they day you cash out of the category. The elliptical brings with it some messier math.

So as product managers, we compete about and in many limit cycles.

Limit Cycle 07

Each of our features are either about a limit cycle, like the red dot on black circles, or in a limit cycle, like the red dot on the thin blue circle. Each red line in the factor analysis on the right corresponds to the radius of a limit cycle on the left, except inside the blue circle. The red dot is you. Inside the blue circle the factor line is attached to your red dot. All the limit circles are inside a hyperbolic surface. We could just say F2 is a belief function under distribution. Or, we could learn to draw the hyperbolic surface first and fit the circles inside it later.

Realize that you are a fast follower of your whole product components’ providers. You are using someone’s APIs, you follow them, you chase them. It doesn’t feel like pursuit and capture, because they keep their third-party developers informed. Or, do they? Value chains involve limit cycles as well. And, after doing the math, it might be quicker just to buy their company and integrate their functionality–the pursed captures their pursuer, not a good thing when Twitter or Microsoft did it.

As for the Zombies, the last page still eludes me.

Comments?

Spatio-Temporal Maps

February 16, 2015

Saturday, I looked some of the pages linked to a visualization site I came across over the past week or so. A visualization of the trains out of London and how the trains changed travel times.

Spatio-Temporal Mapping

Spatio-temporal maps have been a topic of mine for decades. Each of the circles represents a half an hour. Here things are fairly straightforward. But, the realities on the ground are quite different. Yes, the train takes you there quickly. Yet, step off the train, and suddenly it still takes five minutes to cross the street in front of the train station. Things slow down. The 3.5 hours it took to get to Neiuweschans did not deform the map so the physical and temporal, the spatio-temporality, stayed aligned. If you map by time, distance gets deformed. Well, not in this viz. But, try flying to China and then taking the train to your home, several days away via that train. That map would get bent up quite a bit.

Since San Antonio has been my hometown if I ever had one, and having worked in Austin at too very different times, I travelled back and forth a lot. At times I took the Greyhound. Once, on Thanksgivings Day, I blew a hose, popped the hood, opened my trunk, someone pulled over, took a look, dug around in the camper topped-pickup truck found a hose, put it on, filled my car with water, and sent me on my way gratis. Dad didn’t get to tell me off. Thanks. And, I didn’t have to walk 45 minutes to get to a phone in what was at that time ag wilderness. Now it’s convenance stores, burbs, same distance, different mindset. Same spatial, different temporal. Well,  tore up the concrete since then and changed the physical as well. Roads get wider, flatter, and straighter over time.

So here would be something to map and look at the math behind intrinsic curvature. Well, try to if you will. So I pulled the northbound distance and time data for the cities between San Antonio and Austin. I threw away the first attempt. I modified the second. I waffled on how to represent the gaps and lags. Then, I realized that the physical, the miles were continuous, as were the times. I used horizontal bars for each quantity. To get both bars ends to line up meant bending the bars, aka introducing curvature. Except for one thing, I’m working in MS Paint. I know all the tricks. Actually, I learned a few Saturday.

 

There were four segments. Two of the towns were obvious. The third was just pulled out of necessity. The Greyhound used to pull into Kyle, so I know it’s there, along with DQ and a Wachenhut staffed county jail on the frontage road.

I did not pull the southbound data.

So here’s my spatio-temporal map.

Spatio-Temporal Map 01

The graphic at the bottom uses spheres to represent each maximum quantity. The minimum quantity is a smaller circle on the maximum quantities sphere. I put the two larger spheres out front and the smaller ones behind them, so both the spatial quantities and the temporal quantities could maintain their continuity. The line charting had gaps. That just isn’t real. The world is seemless, so the spheres let me present that continuity.

The leftmost sphere represents the minutes traveled with the larger circle. The smaller circle represents the miles travelled. The leftmost sphere is blue because travel time trumps distance travelled. That making it a slow segment of the trip. The travel represented by the second sphere is black, because the miles travelled trumps the time travelled. Again, this sphere has a smaller circle on it representing the shorter quantity, time. The two spheres contact each other miles to miles. That would be the smaller circle on the first, and the outer circumference of the sphere on the second. The third sphere is like the second, but they contact each other times to times, aka the small circle on the second sphere to the outer circumference of the third. The fourth sphere contacts the third, miles to miles.

Too complicated, I know. With a better 3D package, it could be clearer.

Each sphere’s rotational axis is shown. The system of spheres are organized along a curve, rather than a plane.

I went on to draw a curvature graph based on the same data, but the formulas didn’t give the correct results. The arc length of the arcs are too long. The red line edits a spike out of the graph, because it too isn’t real. Again, the road is seamless.

Spatio-Temporal Map 02

I continued my quest for a curvature view with this, the last one.

Spatio-Temporal Map 03

No explanation for this one. I did manage to get a nice arc, but instead of covering the first three points, it went all the way to the fifth point, to Austin, fitting well, but missing the point.

In these diagrams, I used hard data. Well, hard for the moment. I did go back to get the southbound data and found it at odds with the northbound data. Construction can account for why the trip south took more time. Traffic could do same. I did get to that data later in the day. Escaping the big cities eats up the time on this trip. Still, we can consider the hard data. But, there is a soft component. Back during the dot-com one days, the trip was lit up all night. The convenience stores/gas stations stayed open all night. This shortened the psychological distance. These days the speed limits have been reduced for revenue generation purposes–new speed traps. But, I still remember making the trip from south Austin to north San Antonio in 45 minutes. Forget that. But, yes, the speed limits affect the psychological distance as well.

So tying this to product management? Two things:

  • The original train visualization showed a process over geography. Sprints are such a process. And, I’ve talked about product manager geography previously in this blog. For me a roadmap is a map, not a list. Populations are like lakes. Come up with your own analogies. Make your map a real map.
  • Consider my maps to be maps of a user experience. When I reach New Braunfels, please don’t make me open a Wal-Mart popup window. I don’t have time to stop. Your features are organized like trips. Different outcomes, different trips. Done again and again, it becomes familiar and routine. The user knows their way until Agile changes something and DevOps thought nothing of injecting a bug into the user’s UX. Click here, then click there is a geography, a series of histograms/long tails, and flow or psychological time.

Enjoy. Comments.

Surfaces

February 7, 2015

When you continuously look over time at your frequency of use long tails for the functionality in your product, you end up with a surface. I’ve not converted my histograms into nice neat equations, but this YouTube brought surfaces to mind. Similarly, you content marketing, financial results, and progress across the technology adoption lifecycle, if you do such things can be surfaces as well.

Requirement fitness can likewise be modeled. This time, another YouTube brought this to mind. Take the original curve to be the customer’s curve, so the second curve represents our having met that customer’s requirements. Notice that the second curve is the content layer of our software as media, and that our underlying technology is not represented at all. Products foster adoption. Products in the B2B early adopter projects are about the client’s content, not the underlying technology whose adoption is being fostered. The shapes of these surfaces will persist in a given population. In the aggregate late main street phase, the B2B early adopters’ surfaces can be brought back as mass customizations, or simpler templates.

Overall, the technology adoption lifecycle looks like a NURBS curve. It shares characteristics of a uniform B-spline as the curves and distributions are different between the bookends of startup and bankruptcy. Given the uniform B-spline works, we can move to NURBS curves to represent the changes in distribution/curves moving from the Poisson game to the vertical’s normal, the horizontal’s normal, and the late main street’s/consumer’s normal. Laggard/device/cloud is probably a normal as well. The Telco normal was said to be 10x that of the first dot com that lived in the early main street phase of the technology adoption lifecycle. Such weight shifts would show up in the number of standard deviations of each of the normals, and in the weights of the NURB curves. A uniform B-spline repeats the k+1 curve until you reach the n-k curve where the curves are symmetric to the first k curves. This repetition illustrates the purpose of management in the sense of not declining on the decline side of the technology adoption lifecycle. Not declining will still look like a decline since the area under the curve still adds up to one no matter how big in terms of standard deviations the normal is or becomes. The probabilities get thinner, the margins decline.

Discontinuous innovation gives you new distributions, new populations of prospects, new revenue sources. Continuous innovation stretches out your current distribution which in turn thins out your probabilities, and rapidly regresses to the mean. Rapidly might mean five years or so, but the typical CEOs tenure is two years, so even a continuous innovation will make its sponsoring CEO into a business press hero.

Comments?

SBIRs

January 25, 2015

One day, our founder decided to go to attend a SBA training program. They taught him about a business plan, and recommended that he answer the RPs requested in DARPA and DoD SBIRs. So I got t read a lot of SBIRs. And, I got to waste time writing proposals. Reading SBIRs is one thing. Replying to them another.

Our technology was about decision making in loosely coupled networks. This was back in the day before Microsoft hijacked the term loosely coupled network. DARPA had inferential warfare in mind. They took the OODA Loop and made it formal. Then they looked at the individual commanders doing their OODA loops from the perspective of the commanders of those commanders, and the providers of external services for things like artillery, and air strikes. Lags were involved as were conflicts of interest, so some other researchers came up with solutions built around shifting points of view. Nice stuff. Stuff you’ll see executives asking for in about a decade as the officers trained on the stuff move into the private sector.

An army SBIR was asking for tools that would give them the bigger picture of large-scale coordinated hacks. This involved masses of streamed data from server logs all over the network. In discussions with the lead for this particular project, the lead insisted that what he was asking for could not be done. Well, the company I worked for before I got involved with this founder could do it, but probably never thought to sell it to the federal government sector, because of the overhead involved. They got acquired so the VCs could leave, and the technology vanished. The acquirer had competing technology that couldn’t do the job. These SBIRs are research projects, phased research projects. Get into Phase I, or forget about it.

In another discussion, we were looking at a later phase of a project, this before we learned not to do this, and found that SBIRs are awarded to academic researchers, not technology startups looking for clients. So it boils down to SBIRs not being the way to go. After an SBIR project, those academics can form companies that sell the SBIR technology into the private sector, but the private sector won’t startup within one of these projects.

Subscribe to SBIR lists, read SBIRs, get a grasp of future technologies, do your research thing, know how your market populations will change as the technologies in those SBIRs are adopted. But, don’t write proposals in response to SBIRs.

There are companies that respond to SBIRs, but they were set up to comply with federal service acquisition laws. A bare bones software startup does not exist in that world.

Comments?

The Bowling Alley

January 24, 2015

I’ve owed this blog post to one of my twitter followers for a long time, so finally.

The bowling alley is a place on Geoffrey Moore’s Technology Adoption Lifecycle (TALC). I remember it as the first or second of his books on the topic that I read. The other one was “Inside the Tornado.” The bowling alley book is apparently out of print. I may be totally hallucinating, but I think I had it physically in my hands. I read those two before I ever read “Crossing the Chasm.” I read a lot of the same stuff over and over again from one book to the next, but Moore follows Tom Peter’s practice of giving away your methodology while constructing a new one. After the dot bust, Moore moved into the more orthodox regions of standard management practice–stuff startups can’t do, or at least startups that are fostering the adoption of a discontinuous innovation–something the internet is not today. The internet is a well adopted technology sitting in the late main street and later phases of the TALC. That the internet still fits into the TALC along with smart phones and the cloud tells us that the TALC is still relevant. Even if nobody pays attention to it these days.

One thing we hear is how risky innovation is, particularly discontinuous innovation, the kind of innovation that creates new wealth, new categories, and new companies. The bowling ally is a risk reduction mechanism. Risk be damned. Yes, if you do the orthodox pro formas and business plans, you’re boat gets sunk. The risk manifests itself. Management practice inserted that risk. Thinking economies of scale inserted that risk. Stage gating on a guess, or gut inserted that risk. Well, stop it. We can mitigate our risks via the bowling alley.

Moore’s bowling alley starts with the early adopter. That early adopter runs a business in a particular vertical. That early adopter runs the whole business, so you can span the enterprise, or focus on a few business or functional units. You don’t want to do anything horizontal for the early adopters, since you will be selling his application into his vertical. The early adopter will pay you to build his product visualization using your technology. You won’t need VC money yet. You could potentially bootstrap.

Given you know the vertical you will eventually enter, stage gate the early adopter engagement on that vertical. Is there enough seats and dollars in the vertical? Are you providing real competitive advantage to the eventual economic buyers in the vertical? Is there a real market, or is the use of the application driven by laws requiring use of the application, or reporting? Be careful here. Is there enough IT horizontal seats in the vertical? You’ll need those IT people, because the very last thing you do in the bowling ally is enter the tornado where you are selling to the IT horizontal. You get them on board during the vertical. Now, is too early.

Moore suggested engaging the technical enthusiasts in the vertical you are entering, as they might surface an early adopter willing to use your technology. In the figure below, I’ve color coded the bowling ally. I omitted the relevant technical enthusiasts. I’m using a overhead looking down view of the TALC. This will enable us to see adoption and sales of our products as vectors, and in the bowling alley in particular, a collection of Poisson games, games or unknown populations. Moore uses a normal, but after seeing a visualization of startup financial data, I’ve seen it as a Poisson distribution tending to a normal. This was irrespective of the bowling alley.

Research

 

 

 

 

 

 

You don’t see companies going through the bowling alley. I interviewed at one, the one that created the idea of demand pricing. The airline industry was their first client, their first lane in their bowling alley. They had other clients as well. Yes, companies do this. They do it to productize and drive the adoption of their discontinuous technology. You wouldn’t do this for continuous innovation/technology. You do see companies getting stuck in a highly profitable vertical. PeopleSoft is one example.

Doing the bowling alley is a slow process. You want to do eight custom development engagements for early adopters. To keep your intellectual property, you’ll need to give the early adopter something. Moore talked about a two year period of exclusion. That’s two years after delivery where you don’t sell the application. The early adopter wanted a competitive advantage, and gets it during those first two years. All is not lost, since you can have a very broad scope, deliver functionality inductively, deliver functionality as minimal marketable functionality, and engage in management consulting to help the client maximize their competitive advantage.  You’ll have plenty of time with the earlier lanes of your bowling alley. Later, you won’t.

In the next figure, I’ve illustrated the bibliographic maturity process as feeding the technical enthusiasts, some of whom may advocate attractive technologies to their business unit executives.  Again, not to IT. IT will not buy never adopted before technologies. When productized, business unit executives do buy applications that do what they need even if the technology is discontinuous. Of course, these executives are the least risk adverse executives around.

Inbound Idea

Notice that the outer edge of the technical enthusiast phase is gray to indicate that this edge is porous. The outer most red segment represents the technical enthusiasts that can advocate. The inner segment that is not red is the tornado and IT horizontal. The bibliographic maturity process is shown to the left. Since the 60s, we have allocated basic research to universities. Basic research is the kind that breaches physical constraints that are at the core of discontinuous innovation. Ideas move via tennis shoes and show up at the perimeter of a firm where they are subsequently brought in house and commercialized.

When stage gating, you should also consider the spread of your early adopter engagements across the industrial classification scheme that economists use. Moore suggested eight early adopter engagements each in a different industry. Scattering these engagements across the classification scheme enables you to move up and down the vertical with minimal effort, and it enables you to sense economic events via the normal operation of these eight businesses. Different industries propagate economic events at different rates. While one of your lanes closer to the event slows down, all of your lanes will not slow down at the same time.

Industrial Classification Scheme

The figure shows both the movement and sensor net effects of having a collection of well placed lanes.

Eight engagements are taken on serially, one after another. Doing more than one at a time requires us to grow our headcount and capabilities. In the next figure, I start out with one engagement or lane in the first year, doubling the number of engagements in the second year, and doubling the engagements again in the third year. Since my aim is to continuously do discontinuous innovation, I transition to another discontinuous technology once my eight engagements for a given technology are underway. The figure shows subsequent technologies. The figure reflects a very clean process where reality is messy.

Eight Lanes

Now, imagine wrapping the above figure around the radius of the tornado and IT horizontal. Each of the products would be represented by a vector extending from the technical enthusiasts  and ending at the tornado. We ended up with the following figure.

Eight Lanes on TALC

In this figure the products are scattered around the industrial classification scheme. Thick red radial lines represent ongoing product development. The brown areas show how the radials get shorter and shorter as we approach the last engagement or lane in our bowling ally for a given technology. The last engagement will not be waiting around in its vertical. This decreasing engagement window happens because we will combine all our products into a single application that brings all the users with it as it enters into the IT horizontal. The blue areas illustrate where we begin to focus on the IT horizontal. The red radials represent our vectors and the Poisson games associated with them.

It’s messy. There is a lot of work involved in getting across the bowling alley quickly. The goals change. Ultimately, the bowling alley sets you up to win your tornado competition and win your market leader designation, and market power market allocation that grants you a near monopoly for years to come.

Don’t listen to the siren’s call of risk, risk, risk. Mitigate those risks by taking the time required, and putting in the effort to cross the bowling alley.

Comments?

 

Evolution, Intra and Inter Phase

January 18, 2015

The day after I posted the person that wrote the blog post, “Pioneers, Settlers and Town Planners,” Simon Wardly told me that in his opinion there was no correlation between his Evolution concept and my take on Moore’s Technology Adoption Lifecycle. So I’ve wrestled with this for a bit now.

In his tweets, he mentioned evolving practices. So I saw that as Moore’s task sublimation, a requirement for moving from early main street phase to late main street phase, from serving geeks to serving consumers, from free to paid services. A lot of things have to evolve to move from the phases on the left to the phases on the right. SAP had to eliminate their dependence on professional services to move into later, more pragmatic populations of later adopters. Marketing content similarly has to evolve to fit same. So I was still seeing this evolution as from one phase to another, aka inter phase view of the TALC as a process or network. Still, his tweets on the matter were insistent. So it came to me. I was gently reminded of all the disappointing things I see in internet companies today, the intra phase view.

My old Slideshare, “So you don’t have a Market, Great!” hinted at the fact that most innovations are not disruptive and do not always start at the beginning of the TALC and flow through the phases. Verbiage like “Early Seed Stage” make it seem like they do, since early seed stage was something specific back before the internet. Now, it just means your first money, regardless of the underlying innovation. These days there are no underlying innovations. We are replicating adopted stuff. We are starting in the late main street phase and not moving across the TALC in any real sense. A bank should be funding the stuff we are doing today.

Wardley insisted that there is no correlation between his Evolution and the TALC, because the way he sees it, his evolution can happen inside a single phase of the TALC. This has nothing to do with the value I saw in Wardley’s maps and mapping technique. I think that product managers will find it useful. But, there is that other view, the intra phase view. Thanks for getting me there. I know that most product managers are doing continuous innovation, aka evolution, within a single phase of the TALC even if other language pops up from time to time.

Wardley’s s-curve view sums up an argument that Rich Chapman had with product managers back in the 2009 timeframe about how a web service doesn’t need a product manager. Where the s-curve flattens, the value of a product manager likewise flattens. There are webservices out there today that have been around forever and have not changed in forever. They still generate income for their owners. That was Chapman’s point. He wasn’t wrong. Yahoo is another such service. Mayer’s would be better off leaving it alone, and trying to find a new technical discontinuity that could be overcome and serve as the genesis of a new category. Search is so over. I’m not so much against product managers having jobs, but more importantly, product managers finding the steep side of the curve, because those jobs are more interesting and fun. That webservice that doesn’t churn its code, does put out brand new games every year. They just won’t go back and fix things in the old games. They won’t spend programmer time where there is no particular upside.

When you build a conceptual model, do realize that every concept is subject to adoption, has a lifecycle, and has an S-curve. A concept is never static. They evolve. They evolve whether or not they are technological or otherwise. We are moving whether we want to admit it or not. Much of the constant change mantra is nonsense, because non-technological change is very slow, and technological change is very noisy in your face, but much slower behind your back. Change includes churn. Don’t churn.

Go with my recommendations in my prior post. There is much to be learned from Wardley.

Evolution or Product Roadmaps as Maps

January 15, 2015

I’ve built my product strategy practice on the Technology Adoption Lifecycle (TALC), the thing Geoffrey Moore talked about in his series of books. I tied it together with other validating conceptualizations. I used it to build product roadmaps that were maps, rather than the lists that we call product roadmaps today. They were maps of populations and concepts, layers in the GIS sense. I did this back in 2002 or so.

In the past two weeks, someone tweeted a link to an article in @swardley’s blog, “Pioneers, Settlers and Town Planners.” I was surprised to find the TALC being restated by technology/IT management people, rather than markers. They look at the process as flowing

  1. Genesis
  2. Custom
  3. Product
  4. Commodity

Where we marketers see the process as flowing

  1. Technical Enthusiast
  2. Early Adopter
  3. Verticals
  4. IT Horizontal or Early Main Street
  5. Late Main Street
  6. Laggard
  7. Phobic
  8. Non/Post Adoption

The early adopter is a member of the vertical we decided to enter. The vertical of the verticals in Moore’s bowling ally.

More globally, these two view are looking at the same thing, evolution, an evolution of discontinuities in populations and the underlying technological platforms. I bolded every other item in the technology view, and the marketing view to tie them together.

The underlying evolution also changes the view from the automating layers and automated layers, aka the Software as Media model. The Software as Media model flows

  1. Automating Technology (Carrier)
  2. Automated Content (Carried)
  3. Automating Technology (Carrier)
  4. Automated Content (Carried)

Same bolding applies.

So we have lots of models of evolution. The mantra of constant change is false. If you understood business rules from a management perspective, rather than a DBA perspective, you’d see that letting management change their own rules would reduce programmer involvement, which in turn make most change disappear. Change in a population is slow, so automated content doesn’t change all that much. The automating technology changes much faster. Dividing automating and automated helps, so software architects should leverage these as layers; likewise, marketers. These same architects could do the same likewise with the other evolutionary models.

After reading @swardley article, I’m now reading his blog in it’s entirety. So the next post, led to “On Services,” which led to another view of evolution, the Wardly Map, a physical map. See Simon Wardley’s video on Wardly Maps. Wardly added the TALC phases to value chain mapping.

We are always talking about value, but it’s a limited discussion. Value is a vector that happens to reach through your interface. When selling to economic buyers, the point is economic, aka far away from the interface. The user helps the economic buyer reach their economic goals. In value-basing, the goal is to extract say 15% of the economic value created by the economic buyer and users enabled by our products. This makes the preaching around listening to the customer a real mess. Agile developers would hardly be talking to the economic buyer. Hell, we hardly do so either. Value chain mapping maps out processes, needs, users, and technological elements reaching across the reach of the economic goals. The Wardly map is a great tool for this purpose.

I never understood the list perspective of the product roadmap. I’ve written about geographies and geometries, the stuff of maps in the GPS sense. Bach when I was the product strategist for NHDS, Inc., I built the map reflecting the populations and technology. I did both the marketing and technology views on one map.

Have fun. Leave some comments.

Media + Message = Carrier + Carried

January 4, 2015

In other posts, I mentioned a carrier and the carried. A media is composed of a carrier and a carried. We could be talking radio as a media, or a canvas and water paint as a media. The media being the carrier or the physical means. The sound we hear while listening to a radio: the DJ, the music, the advertisements; or the painted portrait or landscape as the message. The message being the content carried to by the carrier, the media. The carrier and carried, the media and the message are taken together inseparable in McLuhan’s quote. They are beat together and interact to become one thing composed of many things. Media turns up in the oddest places: software is a media, and in the technology adoption lifecycle.

Now when we automate a media like video in software, it’s obviously a media/medium. Or, when we develop a game, it too is obviously a medium. We even find ourselves in media categories competing with other media in the hopes of a big hit. We engage in a hit-based, front-end of the long tail, y-axis convergence, business that fundamentally doesn’t look like the software industry, or what we formerly called “tech.” Monetizing on display ads affects our businesses similarly. As a business, we are the business our monetization puts us in, not necessarily the software business. Display ads is a media proposition. The size of your audience matters more than your code.

But, walking away from that, ordinary software is a media. Software as a media is composed of carrier components both hardware and software, and carried content. It’s the familiar division between “What” (carried) and “How” (carrier) But, the division is messy. Too many people get this wrong, even when objects, data structures, coupling, and cohesion try to force some architecture on the issue. At the level of code the question becomes which is which? The index used when iterating through a list is carrier; the length of the list, possibly carried; the content of the list, carried if it originated in non-carrier domain. If the list is a list of commands originating  from the software itself, call it meta carrier, so it originated in the carrier domain. What is which is complicated.

Software as a technology gets adopted over time. Geoffrey Moore’s books, all of them, not just Crossing the Chasm, applied the Rodgers’ Diffusion of Innovation framework to the technology marketer’s work of creating a category and working through that category’s lifecycle. A category is created only for a new discontinuous innovation. Moore would have us begin at the beginning. Most of us don’t. These days, with the internet or devices, we start in Moore’s late main street phase. We start out post geek, where free is not a culturally driven demand, where customers will pay to play, where we, returning to the software as media model, are delivering the carried. The developers typically remain focused on carrier exclusively. Marketing should be focused on carried. The category’s lifecycle phase is focused on the carried.

If we started in the beginning, we would be serving the technical enthusiast, a carrier focused bunch. Then, we’d move on to productize our technology by building one client’s product visualization. That client being the B2B early adopter who expects to create a competitive advantage, value in depth, well off the interface. That client is a member of the vertical market we will serve later, both of which are carried focused. While developing this client’s application, we would include IT roles and spend increasing amounts of time on IT’s needs, carrier. We would have to split our efforts, so one team would remain carried focused, while another would be carrier focused. Then, after repeating this Early Adopter, Vertical, IT Horizontal sequence over and over in the bowling ally, we would cross the tornado in the early main street, where the focus would be carrier. Then, we would transition to the late main street that we discussed earlier. The phases are not short. That saves us. There is more to these phase shifts than just what happens with the software as media model. But, relative to the software as media model we move from carrier, to carried, to carrier, to carried. In the latter, we will end up seeing some of our technology commoditized, in which case, we will return to carrier to rectify that.

I covered the phase-driven changes, as they apply to the software as media model, a long time ago in a presentation, So you don’t have a market? Great!

So what brought this up tonight? A review of linear algebra demonstrated this same split between carrier and carried, this same split exhibited by software when seen as a media.

In integration, we come up with an equation of a family of equations like y=Ax+C, where C represents some initial condition that selects a particular equation from the integrals family of equations. In linear algebra, non-square matrices contain leading and non-leading columns. Those non-leading columns are set to a parameter. The leading columns contain variables the solution of which define a family of solutions. By providing specific values to the parameters, you select a specific solution from the family of solutions. The leading columns give us a class; the non-leading columns, an instance. Taking this back to the software as media model, the leading columns are carrier, and the non-leading columns are carried.

Those leading columns at like the control points of a Bezier curve. You can add control points without weighting them, without changing the curve. Later, with shock and awe, weight them, bending the curve-changing the carrier’s reach.

This all fell out of a discussion of row reduction. In a matrix undergoing row reduction, rows containing only zeros are moved to the bottom of the matrix. This reminded me of the distinction in game theory of dominated strategies, which don’t matter, and an be ignored when thinking about world size. Commoditization is one of those black swans where the world size shrinks and once discontinuous technologies become dominated having lost their differentiation. The rows hint at a stack with the top of the stack being the being the ground plane of the x-axis.

Well, enough of that, except it gave me the vision to see the carrier and carried layers of a media, software as media, a little clearer. Leave a comment.

Choice Cultures

December 30, 2014

I came across this TED Talk in my tweet stream, The Art of Choosing. Thanks to whoever tweeted it. It stuck me as another one of those product manager moments. I posted a series of tweets that hinted at the importance of this concept to product  managers, that choice is different from one culture to another. It gets larger as I sit here, so on to the blog post.

I’ve talked about functional cultures in the past. I made up the term. I had not yet crossed paths with epistemological cultures. Eventually, I stumbled on to an academic journal on epistemological cultures. I felt vindicated. There is such a thing beyond my intuition and observations of same. I wasn’t making it up. Anyway, here is the list of related blog posts on functional cultures:

The short of it is that functional cultures are discipline specific. They are the culture of a group of people who work together, think similarly enough to generate a culture, and do their work as a cultural practice, a ritual. They are insiders and everyone else is an outsider. They are a subpopulation. They are an opportunity for late adoption phase customization. They are the remnants of a vertical market, or members of a later horizontal market. They are carried layer people unless we are talking the IT horizontal which is carrier focused. We focus on and start capturing the use cases and conceptual models of functional cultures in the bowling ally of one of our B2B early adopters. We forget them as we start building for the IT horizontal given that we are still to small to serve both. We forget them because it is the IT people that we consolidate across bowling allies going into the tornado. After we forget them, we can run ten years before focusing on functional cultures pays off again in the late phase of adoption.

While the speaker for the TED Talk focused on how more traditional notions of national culture drove the perception of choice, functional cultures present us with similar divides. The worst divide happens at the level of the programmer, because they are unconsciously encoding the mathematical, scientific, business way of choosing. No globalization, internationalization, or localization standards address choice orientation, or choice culture. We take our products global via distributors. We leave everything to the distributor. They market. We don’t. We capture a revenue stream, not a feedback stream. We don’t even realize our products lack of fit to a non-American mindset let alone come to recognize the subtitles of their choice culture. And, as product managers, we were raised on  prioritizing features, averaging populations, washing away differences–differences that matter to our differentiation, revenues, pricing partitions, fitness, growth of populations underlying market sizing–sizing the normal distribution that is the adoption lifecycle. Worse product managers prioritize before they go global.  Yes, we had to prioritize in the past, but recent developments in application architectures have eliminated the need to make tradeoffs.

Comments?


Follow

Get every new post delivered to your Inbox.

Join 1,800 other followers