A product for your product

Disclaimer: the below is a thought experiment describing how I think about innovation and product development, and I don’t actually know anything about the EV space. It’s all for fun. But maybe someone should do this.

Product as an ecosystem

When mapping our business landscape, I like to focus on users and their needs in the “jobs to be done” framework (big nod to Clayton Christianson). A product is some set of components of the supporting value chain that helps them to do that job. Vehicles, for example, solve for the user’s need for transportation (for themselves or others or goods).

EV vs ICE (in red) value chain supporting the customer “job” of transporting people & things

But transportation, itself, has needs in order to be able to deliver that service. If you’ve got an EV you need a battery, if you’ve got an ICE you need fuel. The customer cares about those things only in so far as they solve the primary need, which is transportation — in other words, if you could give the customer transportation without charging or fuel, you wouldn’t be serving the core need any less.

Disclaimer: I this is all made up by me on the fly to model the Wardley Map approach and is most likely wrong in some ways. But being able to expose that also part of the benefit of these tools.

So when we frame it like that, a battery is a product that serves the EV, charging serves the battery, neither directly serve the customer’s basic job to be done, aka problem to solve. If Charging is a product that serves the battery, then Charging — and everything the customer has to do when engaging with charging, like driving to the station and paying for it — is also a feature of an EV, because the customer has no choice to not use it — but if we could somehow remove that feature without changing other things (like price), we would in no way degrade the customer’s ability to do the job.

Less is more

If I can accomplish my needs by hiring fewer products to do jobs for me, that’s a win. Same with my product: I don’t inherently want to hire more features to do the product’s job. Instead, I want to solve for that job, and in an ideal case, actually solve the job without needing the product in the first place. This might mean replacing a whole chain of needs with a single node, which is exactly what the left-to-right evolution of everything suggest should happen.

Thinking about features as products for my product is a helpful heuristic not just to think about how to do the job more efficiently, but also to reframe the user need and think about what kind of features I can evolve to create greater customer value.

If I was in charge of EV charger networking somewhere, for example, under traditional models I’d be laser focused on the direct user needs that I can place against the ICE model:

This drives me to focus on two things:

1. easier and cheaper at home charging, likely by trying to standardize and drive down the cost of charging units, making them easier to install, etc.
2. better experiences at charging stations, through charging speed (which dependent on lots of other costly development), multiplying retail locations to replicate gas networks so I can more easily charge frequently, and maybe entertainment at stations — drive-in movies at your super charger, anyone?

However, if I had this map of the transportation space with EV vs. ICE, it would similarly be pretty clear that the more commoditized refueling component for ICE is a big advantage that creates drag on adoption, but we also know that charging is moving forward as the world electrifies, so I can explore what happens when I either wait for others to close that gap then build off of it, or close it myself and try to lock in an advantage. However, I can see that Charging leans on Access and Battery. Both are potential areas to evolve and push Charging forward.

Access is about real estate at the moment, which has availability limits, but the need there is simple to get to where the power is. Power can be from lines or battery. If we can move access forward, we can move Charging a bit closer to being a pure utility.

Battery, as a technology, is high cost, high barrier space. But battery as a use, that might yield some advantage. So maybe there’s a play to be made in how we use Battery, not in developing Battery itself.

Building the product requirements

What would it mean for Access to move closer to the Utility line? Well, that means “access almost anywhere”, which, for a car, means anywhere it’s parked. That includes:

• your home
• existing charging stations
• other parking lots, and
• the street

The street contains both public and residential components. The residential components already have some charging capability, and now that I think about it, Battery includes the vehicle *and* the home (Powerwall?).

So if Access is an evolving service moving to the right, and I can split Battery, what do these features describe?

Let’s say Access has two sides to it: heavy and light. Charging access existing stations and parking locations exists and takes heavy use plus heavy investment. We can map all that too, but let’s keep it simple. Charging at home is almost solved, and is a light use, light investment, that has to deal with less total power delivery (charge one car a day, not many), and has lower speed.

So my solution has the following requirements:

• One-to-one “light” charging for EVs
• Using existing Street-level (residential or commercial) access
• Using existing Street-level power availability
• Supported by existing Battery solutions as needed
• Using existing Payment solutions

In other words: it’s a Powerwall or other Battery and a charger set plugged into your home or small biz lines, requiring little to no build-out just like your home charger, that takes payment right on site and makes plugging in for a top of as easy as feeding a parking meter.

It could almost be as simple as a power cord, charger adapter, and a Square card reader. A little charging port that comes in a box, you stick it on a pole by your sidewalk, run a power cord to it, and you get paid when a visitor tops off at some multiple over the cost of your electricity.

It’s not that I couldn’t get to the same high-level product plan through traditional means, it’s that I wouldn’t have fully understood the landscape and user needs in a coherent way that would have led me to the “why here” component of a complete product strategy.

And now, I can really dig into what it would take to execute this. At this point, I don’t know if this is truly viable, but I do know that it would change the Charging need in such a way as to practically commoditize it and that should drive EV adoption. I can also think about the things that I can do to create adoption of my solution, because now I can create a second flow of Payment components through my value chain — I have a second customer. Additionally, I can plot what I’ll call the critical path to delivering customer value.

So what I’m going to want to focus on learning about is:

• Sale distribution strategies of the street charger (Access): what needs to be built around existing customer travel patterns (Transportation), including residential and small business (Access-street)
• Payment: Flow of Payment to the owner of the charger,
• Site battery solution needs and use: what is the dynamic of piggy-backing small scale existing Battery solutions on site (Powerwall, Powerwall Lite, etc.) to facilitate a one-to-one level service and drive as much charge (and hence Payment) as possible through.

Note what is not on there from my business’ perspective:

• Utility power infrastructure concerns
• Commercial real estate Access
• Experience management while at the charging site

And other things. These are things that I need to understand, because they are part of the landscape that I am building on, but they are not within my ownership.

In another post I’ll dig into building the tech map, especially software, and how we’re going to turn this little experiment into a more complete product model.