Customer Development for Enterprise Solutions

I’m a big fan of Eric Ries’ The Lean Startup and, by extension, Steve Blank and Customer Development, as described in Four Steps to the Epiphany. What I find most compelling is the focus on minimising waste by making sure that we’re solving a real customer problem. That means spending time with prototype customers before anything is even built.

In the Business-to-Consumer (B2C) world that are most often described in “lean” books, such as Ash Maurya’s excellent Running Lean, meeting proto-customers is a relatively easy task. That doesn’t mean it’s easy to go and talk to them, but almost by definition there are many of them to be found. And if there are many customers, making a few mistakes when talking to a few of them will still leave you plenty to sell to.

Depending on what you’re product is, the process of Business-to-Business (B2B) customer discovery may be quite similar. When developing enterprise solutions though, the problem of meeting your potential customers (and not accidentally wrecking a future sale) suddenly becomes rather more significant.

In this post, I’m going to describe how we’re applying the lessons of Lean Startups to enterprise software development at Sea Level Research. In particular, I’m going to try and provide some insight into how focus on learning what our customers problems really are and how we work with our customers to develop a scaleable, repeatable business model, in the sense of a tech startup.

Getting up close to customers

Sea Level Research enables ports and shipping companies to improve efficiency by optimising the flow of vessels into, and out of, ports. Many people aren’t that familiar with ports and shipping so I’m going to just backup a little and explain some the issues our clients face.

1. Sprint and loiter

Ship fuel is incredibly expensive – $600 per ton in a large container ship that may well burn 150 tons per day (yep, that’s $90 000 a day just in fuel!). Reducing costs is a massive priority. As fuel usage is roughly proportional to the cube of ship speed, “slow steaming” is the new normal.

The problem is that being late on scheduled services also costs a lot of money. Missing a booked berth costs around $15 000 meaning that ships try to arrive early – meaning that they burn more fuel than is necessary.

For tidally limited ports where large vessels can only enter during certain time periods, missing the tide means a wait of up to 12 hours and the costs mount further.

2. Rate of unloading

The enormous container ships now being built (the latest carry 18 000 “twenty foot equivalent” [TEU] containers) take several days to load and unload. The critical factor here is the number of crane moves per hour. For in river berths where the water height varies, this means that the rate of unloading changes with the tide – and surge level. In a just-in-time environment for delivery and removal of containers, understanding this timing is critical for avoiding huge traffic jams.

3. Optimal loading level for export

Part empty ships are expensive to move around so the maximising the amount of cargo loaded onto a ship for departure during that limited tidal window is essential. Knowing exactly how deep the ship can sit in the water and still depart on time is therefore a priority for many exporters.

Great! But how did we find all this out? We certainly didn’t start here. We learned by going and talking to our potential customers.

The Customer Discovery model

There are four essential steps in the Customer Discovery stage of a startup (summarised from Four Steps):

1. Stating the Hypotheses

  • Product hypotheses
  • Customer hypotheses
  • Channel and pricing hypotheses
  • Demand creation hypotheses
  • Market type hypotheses
  • Competitive hypotheses

2. Treat and Qualify Hypotheses

  • First customer contacts
  • Problem presentation
  • In-depth customer understanding
  • Market knowledge

3. Test and Qualify Product Concept

  • First reality check
  • Product presentation
  • More customer visits
  • Second reality check
  • First advisory board members

4. Verify

  • Problem verification
  • Product verification
  • Business model verification
  • Iterate or exit

This is WAY too much to cover in one post so I’m going to concentrate on the second stage here, which essentially where we’re at.

How we’re doing Customer Discovery at Sea Level Research

Suffice it to say that our (or rather my) original hypotheses were (almost) totally wrong.

  • We thought that we would be selling innovative, machine learned quality control software for processing real-time sea level data.
  • We thought our customers would be national organisations who run large scale sea level monitoring infrastructure
  • Our channel was supposed to primarily through academic links and the sea level community
  • Pricing was a real problem issue but we imagined it would be in the region of a $100 000 per customer per year
  • We had no idea how to generate demand – we intended to tender for contracts and exhibit at conferences
  • We had no real idea of the competitive landscape or the market

This last point was the real killer – we couldn’t really find any customers and the ones we could talk to already had home-brewed solutions – and no money to invest in anything new.

What changed?

What changed all this was a chance conversation with a tide gauge supplier (OTT Hydrometry) who had a client (the Port of Liverpool) who had some “noisy” sea level data. Amazingly we’d never even considered ports as a potential customer!

In tagging along with the supplier to a meeting with the Assistant Harbour Master we learned that this real-time data was being used to bring in ships safely over the shallowest part of the Mersey River – with a clearance of just 60cm! The problem was that, under certain wind conditions, the tide gauge reported sea level varied by 1m or more from minute-to-minute (due to the positioning of the gauge). This made the data next to useless for the Port Pilots to navigate with.

Insight

That one conversation completely changed our view of potential customers. We took two significant steps: 1) We joined the industry group where our potential customers met, and started going to meetings 2) We went to talk to the actual end users, the Port Pilots.

What we learned from informally meeting the decision makers at industry events and meeting the pilots, was that we had to work simultaneously at different levels of organisations:

  • the end-users
  • the budget holders
  • the decision makers

The end-users (in this case, the pilots) hold all the key knowledge about how the job is done and what the key problems in solving them are. This is absolutely essential in understanding what the product has to do.

The budget holder has the purse strings and is crucial for learning about the value of the proposition and also for how to sell the idea to senior management.

The senior management are, for significant enterprise purchases, the decision makers. Getting buy in from the people setting strategy is also extremely important.

Creating value

Our meetings with the pilots and the Assistant Harbour Master have allowed us to develop a much broader view of the value we can deliver with the technology we’ve developed. Instead of relatively “simple” data-processing, we’ve learned what jobs our users are trying to get done. That in turn has allowed us to use the data, not just as information, but to provide insight and solutions. In that way we create and deliver value.

Conclusions

I’m not going to pretend that we’re experts in Customer Discovery in enterprise solutions. We’re far from it. I have absolutely no doubt that Steve Blank (and you for that matter!) would have done things differently. Even the process of doing Customer Discovery is a learning journey for all of us. But learning we are and we’re making great progress.

Advertisements

About simonholgate

I'm CEO of Sea Level Research Ltd (www.sealevelresearch.com) - a Liverpool, UK based startup that uses machine learning to predict sea level surges and optimise shipping movements into and out of port. I'm an oceanographer and I'm also a Clojure developer who is interested in democracy and Big Data.
This entry was posted in Uncategorized and tagged , , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s