Markers That Startups Can Use to Identify Early Adopters

Sean Murphy recently explained to a client his perspective on change agents inside a business and the signals that he looks for to identify early adopters.

Markers That Startups Can Use to Identify Early Adopters

This is an audio from a recent conversation where I have removed a few key details to preserve the anonymity of the other party. I have edited the transcript to make the key points from the dialog clear as a stand alone article.

Direct link to download “Marker for Early Adopters”

We look for two markers in people who are “early adopters” or “change agents.” First, they are rarely new transplants. They are almost always they are embedded in the organization and well respected because they have led prior effective change or innovation efforts, perhaps on a smaller scale. And they learn from prior projects by taking an active part in a post project assessment and acting on it.

Why not new transplants?

So typically what happens when somebody new comes to an organization, they look around and say, “we did it entirely differently in my old company–you guys are doing it wrong.” And then they go talk to vendors and get the vendors all excited, right? And these people tend to have very little internal credibility and very little political power to actually make anything happen. But they’re visible because they’re talking to the vendors. And they end up talking to startups because while established firms may not pay them much attention, a startup is delighted to be contacted by someone who works for a large firm.

Change agents take part in postmortems and learn from the past

So we look for tenure and track record. And we ask them for  a postmortem that shows where they documented a prior failure or show me in your last postmortem for the project or the process that rhymes with what you’re fixing, that you indicated an historical awareness of the need.

You’ve got to be looking forward at what’s coming, but you’ve also got to see some effort to learn from past problems.  The likelihood that something will change is stronger if you see some prior evidence of assessment, because otherwise you may be just working with a dissatisfied group.

Are you complaining, producing a study, or actually working to fix the problem?

Technology Adoption CycleSo I’m going through this right now. So I’m working with a client that decided three years ago to write their own software licensing system, which was not a great idea at the time, but not a terrible idea, right? So I’m now out talking to licensing vendors. I tell them, “we have a homegrown licensing system and it’s no longer really satisfactory for many of our customers; we’d like to see what you’ve got and understand how do we might switch.”

I was on a call this morning with a sales guy who essentially looks at me through this little Microsoft Teams session window and essentially asks “so are you complaining or are you going to change? What are you actually going to do with the information we give you? Is this just an analysis or a study that you’re going to put it in a drawer? Or is this a need where you are looking for an outside solution?” And so we talked about that a little bit and mapped out an evaluation plan.

Now the particulars of this situation apply to the particulars, but the sales person was asking the questions that any startup has to ask when approached by someone from a larger firm.

Do you offer something that the customer benefits from standardizing or commoditizing?

There is this line you have to walk: your product has to address a problem which is putting a significant goal at risk, but which is not a primary axis of innovation or competition. Various industries determine what they’re going to commoditize and what they’re going to collaborate on, right? So the one question is, is there an opportunity for a standard here that many people will adopt?

So one of my business partners, Jeff Alison, was faced with a problem: he needed models for the memory chips that Cisco was designing into high end systems.  He talked to a startup that had a promising technology, but it was very early, it was like four guys in a garage. Allison was their first major customer and helped them get the early traction. He acted as a reference and encouraged other memory vendors to work with them. That company became Denali. It became like a hundred million dollar company. They got acquired for 400 million by Cadence.

But Jeff realized that his need for memory models was a problem that was critical to his success. He needed to solve it to meet his system development objectives. But he realized he would not  be harmed if all of his competitors had access to the same solution–more or less. Perhaps he would be a little early, maybe six months ahead because he was working with them early. But it was better for him to make this an industry solution and commoditize the cost. He was already buying off the shelf silicon and IP blocks for his system memory. There was no real  advantage for him to own a proprietary model. Since he had already made the decision to go outside for the memory components, he should also go outside for the models.

Is there a critical goal or commitment at risk?

In this example, there were some high-level goals at risk on a tight timeline. Jeff was willing to work with a startup because his other vendors did not have a viable solution. He really had little to lose. So that’s another marker a startup needs to look for in working with an early adopter:  is this a significant problem that the incumbent vendors are not able to address on the customer’s timeline.

Is this problem putting a goal for a group or a business unit for the company at risk? Is it putting bonuses at risk? Will a failure to manage it successfully appear on the performance review for a manager or an executive? You can offer a capability that’s essential to meeting a goal, or that’s essential to solving a problem or relaxing a constraint that’s standing in the way of them meeting a goal. Some problems appear like a meteorite on a collision course with a important objective. Solving the problem was not o the list of things a team or a business unit identified at the beginning of the planning cycle. But now that its appeared, removing it, or minimizing the effect on a key goal becomes a new problem that needs to be solved.

Related Blog Posts

Image Credit: “technology adoption life cycle” by moxumbic (licensed via 123RF)


Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top