Category Uncategorized

“The Last Car I’ll Ever Buy”

That’s how a developer I know described his recent purchase of a new Mazda 3. His statement has really stuck with me because I realized he was right. He wasn’t planning to take immaculate care of his car and make it last a lifetime. He was talking about the end of the car ownership era, and the rise of the autonomous car service.

I’d think anyone in a technology field agrees that autonomous cars are coming. What I believe many underestimate is how quickly they will arrive (given we are already using most of the technology required), and that autonomous cars will shift the car ownership market to a service-based model.

Think of all the reasons you currently own a car. Convenience is clearly at the top of the list. You need something that is at your doorstep the minute you are ready to leave, and takes you exactly where you need to go. The privacy is nice; just you, the radio and your Clay Christensen-approved milkshake. But that’s about it for the positives. We know cars are expensive to own – between depreciation, fuel and maintenance costs, insurance and financing charges it’s easily the worst investment you’ll ever make.

Now, think of some of the other things we take for granted with car ownership:

  • We take for granted that we will only enjoy the benefits of this terrible investment about 5% of the time (it’s far less in my household). Most of the time our cars sit in a driveway or parking lot somewhere, steadily depreciating.
  • We take for granted that we can only pick one vehicle to serve all of our needs for the next several years, and might choose a minivan or SUV even though most driving will be done by a lone occupant (the alternative of course, is to double-down on the terrible investment and buy a second car).
  • We accept that we are wholly responsible for our vehicle, and if it breaks down or ends up in a collision (even if someone else caused it), it’s going to be a big, unplanned expense.
  • We accept that significant amounts of real estate in prime downtown areas needs to be set aside for parking cars.

So the opportunity for autonomous cars is to meet the needs of the existing car owner with a service that offers greater benefit than the current model. And the opportunity for an autonomous car service is to provide a greater benefit than car ownership currently does.

To compete on cost is just one factor. Competing on user experience – the sum total of convenience, efficiency, aesthetic details – is where the business is won or lost.

 

While people tend to focus on the obvious ‘experience’ benefits of autonomous vehicles, there is equal – and in a way hidden – value in developing a business that addresses the expensive inefficiencies of car ownership detailed above.

Being a digital product guy I’ve found a lot of value in Strategyzer’s Value Proposition Canvas. So let’s apply it to our topic du jour.

If you were mapping out the value proposition for an autonomous car service it would look something like this: (the circle on the right is current state for a car owner, the square on the left represents the automated car service solution. Click for a PDF version.)

Autonomous ValueProp

The Value Proposition Canvas, if you’re not already familiar, is a powerful validation tool in product development. One of key benefits of the Value Proposition Canvas is forcing discussion and agreement on what the customer ‘jobs‘ are. Second, it highlights the positives and negatives (gains and pains) of the method a customer currently uses to get the job done. Finally, it captures the gain creators and pain relievers of the new product/service, which are the assumptions you are making about the values you believe customers will find in your new service. The next step is to figure out how to validate these assumptions – will customers actually see new gains or pain relief in your solution?

In the ‘jobs to be done’ section it’s simple. The car in my driveway needs to get me where I need to go, quickly and safely, ideally in comfort and privacy. If you’re willing to give up some of the gains (speed, privacy, some comfort) by taking the bus, you can spend a lot less money – a value proposition people decide on every day.

Taxis are a longstanding alternative, and have a specific value proposition that makes sense enough of the time to keep them in business. And then there is Uber, Lyft and in China, Didi, which Apple recently invested a billion (yes, with a ‘b’) dollars in. These new businesses have turned the taxi industry on it’s head by providing better service at a lower cost. Specifically, Uber and Lyft offered a key ‘gain creator’: app-initiated pickup requests; and one pain reliever: seamless, automatic payment. It’s worth noting that customers were not demanding these features en masse, but they were the reason Uber was able to break through (among other customer experience improvements). These improvements have been available to the taxi industry for almost a decade, but the atrophied incumbents failed to innovate fast enough.

But the reality is that Uber is just a prototype, the MVP for something much bigger. It’s a way to test and prove that a car service summoned from customer smartphones can work. The human drivers are just the stopgap until fully-autonomous vehicles are available.

 

The reason I’m going a bit inside baseball with the Value Proposition stuff is that strong gain creators and pain relievers are what drive rapid adoption of new products and services. Transformative products often offer gain creators and pain relievers that people didn’t even realize they wanted or were previously not possible. And autonomous vehicles offer all of this. Some of these gain creators – automatically calculating the fastest route, the ability to choose the vehicle suited to your particular need for each trip – are powerful but mostly invisible to customers until the service actually exists. And many of the pain relievers address significant drawbacks of private car ownership (see Part One) which we simply take for granted in the absence of a viable option.

So let’s step back from simply applying autonomous technology to the next car in your driveway. Imagine instead a service, a flexible fleet of autonomous electric cars. Single occupant vehicles, dual and 4-passenger rides, and vehicles capable of carrying 4, 6 or 8 passengers in auto-configuring, private cabins (think limousine privacy barriers that go up and down). Suddenly Elon Musk’s self-opening car door makes a lot more sense.

You summon a vehicle on your smartphone and select the level of service. The system figures out which suitable vehicles are near you, what other pickups/dropoffs each pool vehicle needs to make, and the most efficient route to your destination. If you can picture this system at scale, you can see how the multi-passenger option makes sense.

To use an internet analogy, think of the passengers as packets of data. The network figures out the most efficient way to get them to their destination address – no driver required.

 

Instead of the way we currently pay for taxis or Uber, which is per-use and by length of ride, think of it being a monthly fee, like a transit pass. To position this effectively as an alternative to car ownership the pricing model should mirror the way most of us pay for the vehicles we own.

Based on your home and work locations and tier of service, you would be able to select a plan that could cover all of your commuting needs as well as unlimited trips on evenings and weekends. Let’s say the service has a median cost about $500 per month. If that sounds high, consider that the American Automobile Association estimates it costs, on average over $8,500 (USD) per year to own and maintain a car in 2016.

That’s a pretty healthy monthly-revenue-per-user to work with, considering your target customer is almost every car owner in or near a major metropolitan centre. And again, don’t let the current taxi/Uber business model realities cloud your thinking. Remember these are autonomous, electric vehicles. They don’t incur the operating cost of a driver and run on electricity, which is anywhere from a half to a third of the cost of a gasoline fuel source. Remember a single vehicle can meet the needs of a dozen customers throughout the day. And at night while most of the city sleeps, these cars can do double-duty as delivery vehicles, with seating configurations hot-swapped for shipping racks, re-stocking the city with commercial goods (think of this as the ‘last-mile’ for the imminent driverless trucking revolution).

If you’re thinking this transformation will take a decade or more, think again. As I said earlier, the value proposition of driving one’s own car vs. taking public transit is something people evaluate on a daily basis. The choice between a legacy taxi and Uber shifted so quickly many cities have no idea how to deal with it.

In a few years my developer friend will decide the convenience of his faithful Mazda3 is no longer worth the insurance and gas he puts into it. His decision will be based on the same logic as people today who are ditching their land lines, cancelling their print subscriptions, and cutting their cable. The transition will be easy (far, far easier than the hassles involved in buying a new car) and it will be permanent. For all the hype around autonomous cars, the biggest change they introduce will not be the hardware so much as a change in the business of cars.

In particular GM appears to be well positioned to take the lead in building the actual vehicles at scale, but as Uber has shown, the real business growth potential is in the software and service.  The companies that position themselves for this eventuality will be the ones that will truly dominate the automotive industry in the next decade.

– July 6, 2016

Drowning in (Technical) Debt

If you deal with software, you deal with technical debt. I’m not just referring to people involved in creating software, I mean anyone using software. Technical debt is the result of compromise, sloppiness or lack of knowledge. It’s the enemy of any business, leading to wasted productivity and unhappy customers.

If technical debt is something you’re already well aware of, and you’re more interested in ways of getting rid of it, you might want to skip ahead. Plenty has been written about ways to avoid creating technical debt (refactoring, test-driven development etc.), but what I’m addressing in this post is more pedestrian and practical – how to you find the time to fix the technical debt you already have?

First coined by pioneering programmer Ward Cunningham, technical debt is perhaps most easily understood as what happens when a developer decides to (or far more commonly, is asked to) take a ‘fix it later’ approach to a known software issue. Of course, ‘later’ never comes, as new work comes in. The problems that technical debt causes typically aren’t visible to the people setting the business priorities – because they’re not the ones dealing with it.

But just like financial debt, companies pay interest on technical debt. Interest in the form of time spent; doing manual workarounds, rebooting servers or worse, security breaches and lost revenue as a result of downtime. And just like financial debt, the more technical debt you accumulate, the more your developer ‘budget’ is going towards interest payments at the expense of actual project work.

A brief aside – I’ve mentioned The Phoenix Project before. It’s a great book that does an excellent job of illustrating the impact of technical debt in a real-world context. If you’re having challenges getting buy-in from your IT management to pay down technical debt, I suggest you buy a few copies and pass them around.

Fine. Technical Debt is bad. So now what?

As mentioned, much has been written about avoiding technical debt, and hopefully your development teams are already adopting practices that minimize the amount of technical debt that gets onto production. But in my experience, the more common challenge iswhat to do with the technical debt you already have? 

Developers are usually the ones who carry the burden of technical debt, and are often the least empowered to advocate for fixing it. An hour here, 15 minutes there – over the course of a week or a month doesn’t seem like a lot, compared to two or 3 days to actually fixing the root cause. It’s hard to get buy-in to fix any one issue.

However when you end up with 10 or 20 little issues that individually take up an hour or two every week it becomes incredibly disruptive. Worst of all – these issues often appear sporadically and require immediate attention – aka unplanned work (another recurring theme from The Phoenix Project).

So how do you build a case for getting executive buy-in for fixing technical debt? As usual, the key is creating visibility.

If you use development software like Jira, Pivotal Tracker or Rally, you probably already have the tools and processes you’ll need. In the example below I’ve created two tickets in Jira. The first, TECHDEBT-221 is an ‘open ticket’ that I’ll use to log developer time whenever someone needs to go in and perform the workaround caused by a single broken application. Each time the task is repeated, it’s tracked in the work log at the bottom, and cumulative time spent on the workaround is easily visible on the right (to date, three and a half days).

TECHDEBT-211

 

Then, I create a second ticket (below), TECHDEBT-222, which is the permanent fix for the broken application that will eliminate the need for the manual workaround. So far I’ve logged about 90 minutes investigating the issue, identifying the solution and documenting the fix. Most importantly, the team has estimated the time required to complete the permanent fix to be about 2 days (yes I know it should be story points, I’m trying to keep it simple here).

 

TECHDEBT-222

So what does this tell us? When I created TECHDEBT-221 I created a way of capturing cumulative time spent on a task that I would need to do again and again. While it was fresh in my mind, I also created a ticket for the permanent fix, and then linked the two tickets together. Over time, the hours captured in the workaround ticket increases, and fairly quickly I’ll be able to forecast at which point the effort spent on the workaround is greater than the effort of the permanent fix. In the example above, I’ve already spent a day-and-a-half more in developer hours on the workaround than would be needed for the fix in the first place.

One more thing: If your organization can manage it, a very empowering exercise for your teams is to set aside a dedicated technical debt sprint. Ideally every few months, each team gets to choose the technical debt tickets that have been bothering them the most, and have a sprint dedicated to fixing them. If you’re having a hard time getting buy-in, try getting agreement to a technical debt sprint in August, when most businesses are at their slowest, or pick the last sprint of the calendar year when many shops go into code freeze before the holiday.

If you’ve done a good job of documenting how much time has been wasted on workarounds, and can compare to the time required to fix the underlying problem you should be well positioned to identify the most ‘expensive’ technical debt – and most cost-effective fixes – in your codebase.

– thanks to Matt Drewitt and Brad Botting for the 3 minute hallway conversation that formed this idea!

Additional Links: Interview with Gene Kim, co-author of The Phoenix Project

– posted June 20, 2016

What You Should Be Reading Right Now

The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win 

PPhardcover

This one is in heavy demand in the Info Tech managers group, and it’s excellent. I’d liken The Phoenix Project to the near-equivalent of spending 3 years in an IT operations role, and that’s pretty good for a book you can read in a few days. Get your team and decision makers aligned around the concepts in this book, and you’ll be able to make significant headway in the often misunderstood world of IT Operations and software development.

Also excellent: Who: The Method for Hiring. A fast read (thanks William Russell!). Even if you consider yourself an excellent judge of character and ability, this book will have you rethinking your methods for screening and interviewing potential candidates. Immediately useful, this is one you’ll be keeping at your fingertips for years to come.

Holland 1945

I don’t know how Stephen Colbert came to be a fan of Neutral Milk Hotel, whose song “Holland 1945” he used to close out the final show of The Colbert Report. For me, it was summer of ’97 I think, a bunch of us went out to Simon Nixon‘s cabin on Lake Ontario for a night of drinks and laffs. As we were packing up the next morning there was a CD of Neutral Milk Hotel’s debut long-player ‘On Avery Island’ on the kitchen table – left by a previous guest I suppose as nobody in our group claimed it. So I took it. 

I loved it. At turns haunting and joyful, filled with distorted acoustic guitar, flutes and tape loops, stark bits giving way to furious blasts of noise – above all exceedingly weird and beautiful. I consumed the followup ‘In An Aeroplane Under The Sea’ with equal vigour, the amplified vinyl filling the kitchen at Draper on many a night. That’s where we kept the stereo. We had a couch in the kitchen too. It was a good setup.

Despite doing everything to remain obscure – the band broke up in ’99 and Jeff Magnum disappeared – the myth of the band continued to grow over the next decade. People continued to discover and fall in love with those first two albums, new bands and music journalists would name-check them constantly, and the records continued to sell.

At least one of them was bought by Stephen Colbert. In a profile back in April, The Times’ Maureen Dowd ended her piece with the lyrics to Holland 1945, something Colbert had send her. Dowd connected the song to the plane crash that killed Colbert’s father and two brothers when he was 10.

The fact that eight months later Colbert closed out his 9-year run with that song suggests she was right. A tribute to family, an acknowledgement of tragedy, sadness and beauty, Neutral Milk Hotel is all of those things.

Where the Magic Happens

card27451(via http://thisisindexed.com)

 

Top (?) Digital Trends for 2014

via @paul_mcgrath, an interesting Forbes article on 5 Top Digital Trends for 2014. in a nutshell:

An Identity Based Eco-System: Sites like Twitter and Facebook reflect people’s desire to ‘showcase’ their online identity. Successful companies will design products and services that take advantage of this.

Content Curation and Aggregation: This seems an obvious one to me, but one area this could and should expand into is a more open system for outsourcing personal recommendations from friends.

I have personal communities on Linkedin, Facebook, Twitter etc., and I’ve used services like Amazon and Homestars where I’m effectively anonymous to the community. An intermediary service that could bridge these private and public networks (while ensuring user control over privacy settings) would add the power of word-of-mouth personal recos to online shopping.

Video = Device Agnostic: This is where it’s going anyway, held back less by the technology than the established business models it disrupts. Geofencing video really doesn’t make any sense in the online world, but it’s a significant vestige of traditional television business that will encumber us for a while yet.

The 4 Screen Revolution: Not just 2 screens anymore, but 4! Reminds me of the classic SNL ‘Triple Trac’ parody.

Social Literacy Skills Required: I think this one is the most on-point. There has never been anything like social media in putting power in the hands of customers and regular employees. The point about C-level execs is good too. They can’t fully trust the strategies of their social media ‘experts’ if they don’t understand the nuances themselves.

Reverse Showrooming

Showrooming – the practice of cruising brick-and-mortar stores for a hands-on look at a product but buying it for less online – has been cast as a threat to traditional retail. Target went so far as to pull Kindle eReaders from their shelves to protest Amazon’s active encouragement of the practice.

My personal experience is quite the opposite. I’m a patient shopper. When I think of a thing I want to buy, I research the crap out of it. This is a lot easier with sites like The Wirecutter that can narrow down your choices to a few solid contenders and layer in some candid opinion. But when you find yourself looking at an unfamiliar product in a store at what seems like a reasonable price, what do you do? Of course, you pull out the smartphone and Google it.