What it means to be a product leader

There has been a lot written about how to be a great product person. The skills for being a product leader are different. Here are some of the things I’ve tried to do in my time as a product leader. (Many of these skills apply to leadership in general.)

  • Represent product in leadership meetings. Any organization will have many competing priorities. This includes business strategy, customer needs, marketing campaigns and financial situation. All of these contribute to what the organization needs from the product organization. It’s your job to listen to these competing needs and provide direction to the rest of the organization to ensure that the expectations from executive leadership are realistic.
  • Go beyond buzzwords. The CEO wants AI in the product? Sounds sexy. But what does that actually mean? Delve into the details. If the CEO wants something that can’t be built with today’s technology, it’s the product leader’s job to say that.
  • Clearly communicate priorities. Once priorities are decided, it’s up to you to make sure that everyone on your team knows what they are and how they fall into the schedule and affect the roadmap. Priorities can and will change and the changes need to be communicated quickly to the team, with direction on what other work needs to be delayed or canceled.
  • Empower people. “Empowerment” is a buzzword too often used in job descriptions, with little to back it up. As a product leader, you can’t make all the  product decisions yourself — there are way too many. If you do, you will fail at the other aspects of your job such as working with company executives on overall strategy.
    Let product managers make decisions. Many decisions often have little consequence to the overall success of the product. Is the right timeout for a login 1 day or 3 weeks? In most cases, you won’t know until you try it. Clearly, the right answer isn’t 10 seconds or 10 months. The goal is to build it in such a way that you can change it later.
    Be prepared to step up into the weeds when something critical comes up, but don’t stay there. I’ve had to do QA when time was tight and we needed to get things out. That should be the exception. You’re being paid way too much for that.
  • Make decisions quickly. Inevitably, there will be disagreement among the members of the product team or between product and design. When these come about, it’s your job to make a decision. It’s better to resolve these quickly with the knowledge that most decisions are reversible once you have more knowledge on how customers respond. Don’t let decisions drag out with weeks or months.
  • Elevate the skills of your team. Every team member will have strengths and weaknesses. Help your team members up their game. I’ve spent a lot of time teaching teammates on elements of product design, how to do customer research and how to communicate, among many other things. Some of this had been in the form of classes for the team, others have been in writings.  (You can also find a lot of my writings on product management and customer experience on this blog.)
  • Congratulate in public, criticize in private. You’ll have successes and failure. Celebrate the successes in public so that the team can share in the joy and excitement. When things go wrong, don’t criticize or berate people in pubic. Things will fail; that’s the nature of launching products. Failure is great, if you learn from it.
    Embrace risk taking. If people are afraid of taking risks because they fear public flogging, your products may end up being too saccharine.
  • Hire great product people. If your company is growing, you’ll need to hire more. As important as skills are, fit is more important. You can teach someone how to do market research; it’s much harder to convince them to care.
    There are different types of roles in product organizations. Some are more structured and repetitive. Some require creativity. Put the wrong person in the wrong role and they will be unhappy and unproductive.
  • Say “No.” This is probably the most underrated. Humans generally want to make others happy. Product leadership requires balancing every aspect of the organization. It’s easy to string people along, but it’s a bad idea. It’s better to clearly say no. It’s not possible with the schedule. The technology doesn’t exist. You’d need to spend a lot of money on AWS. Whatever the reason, put it out there. If someone doesn’t accept your “no,” then take it to the executive team for a resolution. You’ll get more done faster and are less likely to burn relationships.

These are, of course, general guidelines. You need to be aware of the specifics of your situation. If you’re in a highly regulated industry, it may have serious consequences if you fail; it’s the product leader’s job to understand that.

How to keep customer feedback from destroying your startup

You’ve launched your product. You’re getting some adoption. People seem to like it. You start to get some feedback. TechCrunch does a write up on your site. You get lots more feedback.

Sounds great, right? In many ways, yes. But feedback can destroy your company, if you let it causes you to thrash in what you are doing.

Your earliest adopters tend to be the most geeky, the techies who probably don’t represent your target customers. (Unless your target customer is techies.) The feedback they give you isn’t going to matter to the general market.

I heard Stewart Butterfield, the founder of flickr, talk about this early on. Some of his users wanted that ability to geotag photos by uploading tracklogs from Garmin hiking GPSes and syncing their timestamps with the timestamps on their pictures. Great idea. I loved it and would’ve used it. But me and 10 other people. It turned out not to be necessary in the long term because cell phones (which are the source of the vast majority of pictures online) automatically embed GPS information.

In the short term, geeks like me found tools like GeoSetter and iTag to embed GPS date into EXIF fields on photos.

There are a few other problems with customer feedback:

  • It’s not prioritized, even by the person giving feedback. Generally they don’t tell you whether it’s really important to them or just an “it would be nice.” Would it affect their likelihood of sticking around? Would they pay more for your service? Would it help you get the word out to more people? Who knows? Most feedback doesn’t come with that level of detail.
  • You don’t know who they are how they use the product. Without understanding the customer’s persona, feedback is less valuable.
  • It’s rarely the case that more small features will make or break your product. There are rapidly diminishing returns on many features. In a lot of cases, there are negative returns.
  • They are unlikely to know what your business model and goals are.

In order to make the most of the feedback you get, you need to organize it. See how much of a certain type of feedback you get. Group similar feedback. Have your product and business teams decide where it falls within the business goals.

This is especially true of business-to-business companies. You’re having one-on-one interactions with the buyer. He’s giving you some interesting ideas. Sales tells you that if you had “one more feature,” they’d close the deal.

Wait. When there are a small number of big customers, you risk becoming a captive development arm. You definitely don’t want to be that. It makes it easy to lose track of your other customers. If your product becomes too specialized for a specific customer, it can hurt your valuation.

You want to take in feedback and harmonize it with feedback you get from other customers and potential customers.

It can be hard when you’re working closely with someone to say “no.” Your sales team might keep nagging you for that feature. (In a future post, I’ll discuss how to deputize your sales team and sales engineers into mini product managers.)

Stay strong. Make sure what you’re doing aligns with your roadmap and will appeal to other customers.

There are somethings early customers will ask for that are no-brainers. Examples are GDPR compliance and SSO. You don’t have to do these right away, but be sure to have an answer prepared on how you will solve these problems.

Yesterday, I sent some feedback to the CEO of a company I’m looking to invest in. It’s an incredible feature. I know it will help them sell to new customers. Of course he should take my feedback: I’m a potential investor, reasonably well-known writer, have decades of product experience and I run UX quizzes on Twitter that people seem to value.

His response?

Sounds like a good idea.

That’s something that we can think about adding to the system. Thanks for the feedback.
That’s exactly the right response. It increases the likelihood that I will invest.

A startup’s guide to doing research on the cheap – usability testing

User research is an important part of the product design process. It can help you make sure you’re building the right thing for the right people and to continue to learn from what you’ve built.

I divide companies into two types: those that are driven by users and those driven by features. User-driven companies pay intense attention to the needs of their users and build products for them. Feature-driven companies focus on what they can do with technology and build those products. You don’t want to be the second.

Needs can be expressed or unexpressed. Some needs that users express may actually be counter to what they want. Important needs may go unexpressed because users don’t know exactly how to express what they want, or the research tools are poor.

There are many types of tools that you can use for research: usability testing, focus groups, ideation sessions, ethnographic research, user feedback, survey research, eye tracking, etc. Too often product managers confuse the roles of these tools and end up with bad interpretations.

Research can cost from nearly nothing to tens of thousands of dollars. In this series, I’ll go through research tools I think provide the biggest bang for the buck for startups.

Today’s topic: usability testing.

You need to assess whether people can understand what your product will do. Ideally, you’d do this shortly after the user flows have been built. Bring people in 1 by 1 and watch them accomplish a series of key tasks. Have the designer and product manager sit with the interview subject.

I like to just give the subject a task and see what happens. (After all, no one is going to be sitting with them while they are actually using the product.) “Order a large pepperoni-mushroom pizza and have it delivered to your house.” Then watch as he goes through the user flow. Have the interview subject articulate their thought process as they perform the task. Where did his eye go first? What was the overall flow?

Only when the subject gets stuck should the interviewer intervene. “Where did you expect to find it?” “Maybe try scrolling further down the page?”

Although ordering a pizza is a relatively simple task, there are a number of steps: finding the restaurant nearest your house, selecting your pizza, adding toppings, special instructions, delivery information, payment, etc.

Some people like to do the testing one step of the process at a time. I prefer to do it all in one pass. There are two primary reasons:

  • Time to completion is a key part of user success. If you stop the subject at every step, you aren’t going to be get a sense of how long he would have taken with your user interface. If it would have taken him 10 minutes to order a pizza, your interface has failed.
  • You get a sense of what other flows the user might see. That’s not necessarily a bad thing, but it’s important to get that sense.

Once the first pass is done, you can repeat the test step-by-test and ask for detail on what was confusing or not.

Usability testing can be done with static images linked together, but I really prefer doing it with live or close to live code.

You can also test a couple of different flows.

It’s important that the subject is told at the outset that he is not the one being tested; it is the user interface that’s being tested. There is no right or wrong answer.

Whom you choose to participate is key. On HBO’s Silicon Valley, the initial response to the compression tool was amazement. All of their friends loved it. Except for Monica, who hated it. Then, we saw the user interface:


The people who loved it, the initial test group, were friends of engineers who were also engineers. They loved this type of interface because it gave them control over every little detail of the compression. Most users don’t want this.

You want to get people who don’t do tech for a living, if at all possible. You want to get people who are as close to your target audience as possible. If your product is designed to be used by senior citizens, don’t have millennials do the testing. (In this example, you’ll miss things like font sizes.)

Usability testing doesn’t need to be a formal process and doesn’t require special equipment.

You can recruit test subjects via craigslist. $75 to $150 for 40 minutes is a reasonable amount to pay. If you sell a product, some of this could be in service credit. For example, a $75 AmEx gift card and $50 to use on your app. I’m also comfortable asking friends and family, if they would be in the target user group.

Usability testing isn’t survey research; you don’t need to interview 1,000 people. With ten people, you should be able to identify the biggest obstacles in your interface.

How autonomous vehicles will redefine cities

The coming of self-driving cars will redefine the urban landscape, in the biggest change since the creation of the Dwight Eisenhower interstate highway system.

Interstates took motorists and money from roads like Route 66 and shuttled them through high-speed lanes with occasional exits. Motorists services sprung up around these interchanges.

Mini towns like Breezewood, Pa., cater to interstate travelers. Creative Commons image by David Wilson.

Much of the impact from the interstates affected rural and suburban areas.

Self-driving cars will have their most profound effects on urban cores, where density provides the greatest value. (In rural areas, individual ownership of vehicles is likely to continue at a greater rate than in cities.)

These changes will not happen overnight or all at once. These will take decades to take effect and timing will vary by city.

Developing the best outcomes will require close cooperation between cities and the private sector.



Parking is the bane of an urban dweller’s existence. In dense urban cores like San Francisco and New York, reserved parking spaces can cost $450 a month or more. Parking meters have strict time limits, costs and fines for violations. “Free” street parking can require circling for 30 minutes or more.

Parking is needed because most cars sit idle for much of their existence; cars in use, by definition, aren’t parked.

With fleets of self-driving cars, users will be able to order cars on demand. Instead of owning a car that is idle more than 90% of the time, riders will be able to push a button and have cars come to them. As soon as a ride is complete, the car can be repurposed for the next rider.

This should lead to a decline in the demand for on-street parking, parking lots and parking garages. Demand for parking enforcement officers will also plummet.

This reduced demand will also affect city revenues. In San Francisco, parking is a $130 million business between parking fees and violations. Parking fines alone are projected to be $87 million in FY2017. (Of course, collection, maintenance and enforcement expenses will also drop.)

Space freed up from commercial and public parking lots can be reallocated to higher value activities like retail and residential, potentially increasing the city’s sales and income tax base.

This can also have positive environmental effects. Heat-absorbing asphalt can be replaced with green roofs.


Creative Commons image by Newtown grafitti.

It’s estimated that more than a third of traffic in urban cores can be attributed to motorists searching for parking. Much of that traffic can be eliminated by substitution of on-demand self-driving cars.

Self-driving cars will also reduce traffic congestion in two other ways: not blocking the box and fewer accidents.

During rush hours in San Francisco, it can take 30-45 minutes to travel 1 mile on a street like Bush St., which funnels traffic to the Bay Bridge. Some of that congestion can be attributed to vehicles that block the box and induce gridlock. As self-driving cars take to the road, they can be programmed to avoid blocking intersections, smoothing the flow of traffic.

Accidents are a major source of traffic congestion as they reduce traffic flow capacity. The rubbernecking effect exacerbates these problems. Self-driving cars should dramatically reduce the number of accidents. When there are accidents, time spent on roadside investigations (which increase the rubbernecking effect) can be reduced based on access to data collected by vehicles.

Urban architecture

With less space designated for parking, space can be more efficiently utilized. Homes no longer need to allocate 1/3 of their space to fitting a car.

Instead of lots scattered around the city, parking can be relegated to staging areas. For example, commuter buses in San Francisco currently park during the middle of the day outside of the core. They come back into the city during the afternoon rush to take suburbanites home.


Creative commons image by Pete Bellis.

Beyond simply autonomy, the sensors in self-driving vehicles can be used to collect and transmit data in real time that can help to improve infrastructure for all motorists.

Potholes can create traffic hazards and cause wear and tear on cars. Pothole repair often relies on motorists to report potholes. With self-driving cars, pothole locations can be detected and sent (along with pictures) to a city’s public works department. Instead of prioritizing repairs to potholes near the most vocal residents, they can be prioritized based on severity and degree of impact to the most motorists.

Signals are timed based on historical traffic patterns, not actual traffic conditions. Weather, special events and detours affect traffic patterns and can create suboptimal traffic flows based on signal timing. Data from sensors on connected cars can be used to optimize signals.


Sensors in connected cars can be used for other purposes that benefit society. For example, data from cameras can be used to identify suspects in Amber alerts or find dangerous suspects in emergency situations.


A massive change of this sort doesn’t come without a lot of challenges, some technological, others societal.

  • Media — New technologies get frequent scrutiny from media. A single death in an autonomous vehicle gets worldwide coverage despite the fact that tens of thousands die in people-driven cars each year.
  • Politicians — You can rely on politicians to showboat without taking into account the actual facts. Consider this fear-mongering campaign ad trying to scare senior citizens. Never mind that seniors will be among the biggest beneficiaries.
  • Regulations — Much of our driving is still regulated at the state level, including licensing and registration. Even self-driving vehicles across state lines can be problematic. We need preemption at the federal level.
  • Security — We’ve seen botnets take down Web sites used by tens of millions of people with little accountability. If sensors from connected vehicles are being sent into traffic management centers, the data has to be encrypted and validated.
  • Privacy — All of the data transmitted by self-driving and other connected cars can be very personal. Steps need to be taken to anonymize and securely store the data.
  • NIMBYism — Anything that involves reallocation of shared resources, such as parking spaces will inevitably face backlash from residents looking to protect their own interests, even if there is a long-term public benefit.

Some of my favorite articles

Principles of mobile design

Five mistakes that product managers make

Facebook could make billions in search. Here’s how.

Creating great products isn’t just engineering them

11 questions for marketing and product interviews

A startup’s guide to doing research on the cheap – usability testing

Why Groupon Is Poised For Collapse

Use your client’s product (and your own)

Why I expect Allo to struggle

Google this week launched, Allo, the latest in its efforts at social. We’ve seen a long Wave of Google social products that have failed. Buzz, Wave, OpenSocial, Google+ on the pure social side. When you look at the subset of messaging apps, this includes gTalk, Google Voice, Google Hangouts among others.

Allo is Google’s latest attempt to compete with Facebook Messenger, iMessage, WhatsApp and Skype.

There is no clear reason to adopt this. Why is a user going to adopt Allo? Is it for:

  • Tons of emojis. (Piece of cake to emulate.)
  • To play command line games? Zork 2016 (Piece of cake to emulate.)
  • Google Assistant.
  • whisper SHOUT. (Piece of cake to emulate. iOS 10 includes this.)

Better to pick one thing and knock that out of the ballpark. You aren’t going to win FB Messenger users over with emoji. Given Google and Facebook’s relative strengths and weaknesses, I’d bet it all on Google Assistant. Another plus: It adds virality to Google’s other products.

The initial implementation of the assistant is an OK start, but there’s a long, long way to go. Google Assistant is like most bots, it overpromises and underdelivers.


One of the challenges in natural language processing is understanding entities. When I asked a friend “Do you want to meet up at blue line pizza tonight?”, I got a search suggestion for “Pizza places nearby”. It didn’t recognize that “blue line pizza” is an actual place. When I said “How about tacorea?” It gave me the correct suggestion of “Tacorea restaurant”.

Having worked in local, search and messaging, I know that entity extraction is an incredibly hard technical problem. So I’m going to be more forgiving than most people. A lot of users will just feel that the experience is broken.

Google is also behind in another way: Unlike Facebook and iMessage (and even Google Hangouts), there is no desktop experience. I wanted to send a link to this post to a friend over Allo (after I wrote it on my Mac), but had to send it via Hangouts instead.

The biggest challenge for Allo will be distribution. I already have plenty of ways to message someone: Facebook Messenger, WhatsApp, Skype, SMS, Line, Twitter DM, iMessage.

iMessage succeeded because it Apple just took over SMS transport for iPhone to iPhone messaging. (Apple was able to do this because it has always been able to dictate the rules to carriers.)

WhatsApp built its base outside the U.S. The primary reason people adopted it initially was to avoid paying the exorbitant cross-border SMS and MMS fees. There was an easy, compelling reason to switch.

Facebook Messenger used its insane time-on-site and hundreds of millions of users to build its user base. They had a massive (and personal) friend graph to work with.

So far, I haven’t seen anything from Google about how it’s going to attract users.

PR tips for startups

6277209256_934f20da10_bGetting attention for a startup can be hard. There are thousands of startups out there of various size. How do you break out from the noise? Here are some tips on the best ways to get coverage of your startup. They draw from my experience both as a journalist and someone who has been interviewed by many media outlets.

One tip that applies to all startups: never spam reporters. It may be tempting to compile a list of all the various tips@ media@ etc. from every tech site and blanket spam them. Never do that.

A reporter’s job is to tell a story, not a story about you.

Companies 1-10 people

You don’t need to hire a PR firm. (You probably can’t afford one anyway.) The odds that a $5,000 a month retainer for your startup will get you meaningful coverage is slim to none.

Here’s what I would do instead:

  • Set up a Google news alert for a competitor and for industry news related to your company’s business.
  • Read about your areas of focus intently.
  • From those two, you should be able to compile a list of writers who cover your space. You don’t need to (and shouldn’t) reach out to every writer at TechCrunch; find the one or two who specifically focus on your business area.
  • Follow those writers on Twitter.
  • Writers will often ask for help on various topics related to their beat. Help them out, help them to understand their space. Do this in a non-promotional way. If you have specific data or consumer experiences, definitely share them.

Me experience is that journalists are relatively forgiving to startup CEOs.

Greater than 10 people

At this point, it begins to make sense to hire an agency.

Here’s how I’d go about it:

  • If they pitch you with “coverage” they’ve gotten in “publications” like PR Newswire or Businesswire, run away. In the era of blogs, you don’t need to pay for this worthless distribution.
  • Talk to the actual person who would be doing media outreach, not just the account rep. Assess whether they are personable. You want someone who is outgoing. Abrasive personalities are not good for PR.
  • Look at what kind of coverage they’ve been able to get for similar-sized companies. Have realistic expectations. (See below.)
  • If you’re in the local space, listen to the kinds of publications they pitch you on and what coverage they can get. In local, you want local and regional coverage. That gets you customers; tech blogs and national press give you credibility with partners and investors.
  • I’d bias to smaller agencies or independent PR people, where your retainer actually means something to them. It makes it more likely that you will get their time.


Startups (and companies in general) tend to have unrealistic expectations of outcomes, especially when talking to major publications like Businessweek, the Wall Street Journal and New York Times. If your CEO spends 30 minutes on the phone and you get a paragraph of coverage, that should be considered a success. This is especially true for recorded radio or TV interviews. I’ve had 20 minute conversations that were edited down to 3 second sound bites.

When the story appears, send a thank you email to the writer. If there were errors or misperceptions in the piece, offer clarifications for future pieces. If there were egregious misrepresentations, call them out in a nice way. Only people like Elon Musk can tear into a reporter.


These apply whether or not you have an agency.

  • Do a blog post about your news and then share it with reporters. At that point, it’s not news. Unless you’re Facebook, Google or Apple, it’s unlikely that a reporter will write about it once it’s out there.
  • Send a link to a story a competing reporter has written. Again, not news. Also implies that the other writer was more important.
  • Send messages that are “EMBARGOED,” except to journalists who have agreed to accept an embargo. (Embargoed stories are ones that won’t be released until a certain time. For example, a product launch.)
  • Send messages that are “Off the record.” Off the record is something that has to be agreed to by the journalist. In general, I won’t say things that are off the record except to journalists I trust.

Have questions on startup PR? Find me on Twitter – @rakeshlobster.

Tesla’s tragic reminder: we don’t have self-driving cars, yet

If you’ve been reading this blog or following my tweets, you know that I’m a huge proponent of self-driving cars. In the long run, they will save lives, reduce environmental costs of transportation and make more efficient use of capital. They will fundamentally change the nature of cities and society.

But we’re not there yet. And we won’t be for many years to come.

8633482886_0f07a15401_oA Tesla enthusiast died recently when his Model S drove straight into a truck that was making a turn. The car’s “Autopilot” mode didn’t recognize the brightly colored truck against the brightly colored sky. Neither did he. (A portable DVD player was found in his car; it isn’t clear if he was watching it. A witness said that it was playing Harry Potter shortly after the accident.)

We’re in the midst of a long transition period in cars and car safety. I’m afraid this won’t be the last such incident.

We have many different kinds of safety and driver-assistance features in cars today. Some assist driving. Others offer semi-automation. The last category is true autonomous vehicles. (There are no vehicles of the last type in commercial production.)

Definitions of what belongs what will vary. But this is how I think about them.

Driver assistant features

These help the driver with alerts or by managing small parts of the driving experience. They check the work of the driver. They include:

  • Anti-lock brakes. The system pulses the brakes to help prevent skidding. Before anti-lock brakes, drivers had to manually pump brakes to keep from hard braking and locking the wheels. With ABS, the system pulses the brakes much faster than a human can. The braking has to be initiated by the driver. These are standard on U.S. cars.
  • Back up cameras and back up sensors. When the car is put into reverse, back up sensors will beep as it detects an object behind you. The closer you get to the object, the more frequent the beeping. Cameras show you what’s behind the car, including things you wouldn’t see in the rearview mirror. Cameras are now in about 60% of new vehicles in U.S.; they will be required in cars by 2018.
  • Lane-departure warning systems. These notify you when you are drifting out of your lane. They use cameras to look for lane markings. The driver still has to do the steering; the system only alerts to mistakes. LDWS are options on mid- to high-end cars.
  • Blindspot detection. When you are changing lanes, blindspot detection systems will alert you when there is a vehicle in your blindspot. This could be an audible alert or an indicator in the side view mirror. BSDs are options on mid- to high-end cars.

Semi-automation systems

These are typically offered on mid- to high-end cars. They actively control the vehicle.  They include:

  • Cruise control. Cruise allows a driver to set a steady speed for the vehicle and it will maintain the speed. The driver can then remove the foot from the accelerator. Even in light traffic, this is a pretty useless feature. Because other cars change speeds, you have to keep adjusting the cruise setting. This has been a common feature for decades.
  • Adaptive cruise control. Similar to cruise control, but the speed adapts to the car in front of you. If the car slows down, your car will slow down.
  • Lane management systems. They will keep you in your lane by using cameras to detect lane markings. They’re rarer than LDWS, but rely on the same basic technology.
  • Automatic braking. These detect imminent collisions and automatically apply the brakes.
  • Automatic parallel parking. These will park your car for you.

Fully autonomous

These systems use a range of sensors including cameras, infrared and LIDAR along with extensive maps databases to drive without human intervention. Alphabet, the parent of Google, is the company that is furthest along in fully autonomous vehicles.

In Google’s testing, there have been no fatal accidents. The only accident caused by a Google vehicle was a very-low speed collision with no injuries.

A long transition

We are in the midst of a long transition. Unfortunately accidents will happen because of a combination of human laziness, overselling of the product and confusing interfaces. The current semi-automation systems have a lot of limitations.

I recently rented a Cadillac STS with a lot of these features. As I drove it, I tried using the “lane keep assist” feature. In theory, the system would keep me in my lane. I tried it on curvy Interstate 280 in the Bay Area, in moderate traffic. As far as I can tell, the system didn’t work. When I took my hands off the wheel, the car would drift a foot into the other lane before pulling me back into my lane. Although I’m a big fan of testing products to the limit, I wasn’t about to do that in traffic.

It’s possible that it was user error. Or a confusing interface. Or I was outside the limitations of the system.

According to GM, Lane Keep Assist and Lane Departure Warning systems may not:

  • Provide an alert or enough steering assist to avoid a lane departure or crash
  • Detect lane markings under poor weather or visibility conditions, or if the windshield or headlamps are blocked by dirt, snow, or ice, if they are not in proper condition, or if the sun shines directly into the camera.
  • Detect road edges
  • Detect lanes on winding or hilly roads

And if Lane Keep Assist only detects lane markings on one side of the road, it will only assist or provide a Lane Departure Warning alert when approaching the lane on the side where it has detected a lane marking.

Lastly, GM says that using Lane Keep Assist while towing a trailer or on slippery roads could cause loss of control of the vehicle and a crash. Turn the system off.

When the LKA or LDW systems don’t work properly, the system performance may be affected by:

  • A close vehicle ahead
  • Sudden lighting changes, such as when driving through tunnels or direct sunlight on the camera sensor
  • Banked roads
  • Roads with poor lane markings, such as two-lane roads

Read more: http://gmauthority.com/blog/2014/11/gms-lane-departure-warning-and-lane-keep-assist-tech-feature-spotlight/#ixzz4DYSRz6QL

That is a lot of limitations to be aware of! It’s too easy to learn to rely on semi-autonomous features that might work 95% of the time but have dire consequences in the 5% case.

Marketing doesn’t help either. The benefits are highlighted in glamorous videos; the limitations buried in fine print. Even naming makes a big difference. Calling something “Autopilot” given the state of today’s technology is vastly overstating the case.

What does the A with the arrow that looks like a circle mean? Beats me.

Car companies aren’t the greatest at user-interface design, often using what look like  hieroglyphics for controls. In my test of the STS, I thought the car had an automatic braking system based on the icons. I’m glad I didn’t try to test that — because it didn’t. Mine was a somewhat unfair test because if I owned the vehicle, I’d probably know what features I had. But if someone had been borrowing my car, they’d be presented with the same set of challenges.

Driver training on the proper use of new features is key. When I went through driver’s ed, I was taught to pulse the brakes to prevent the wheels from locking up. But with antilock brakes, you are supposed to step hard on the brakes. I was taught to put my hands at 10 and 2 on the steering wheel; with airbags, you want to put them at 5 and 7.

Not only are the controls of new features not intuitive, some companies even fiddle with basic features.

FCA’s redesign of the transmission shifter is mind-bogglingly stupid.

The National Highway Traffic Safety Administration’s investigation into the Monostable gear shifter used by a number of Chrysler, Dodge and Jeep vehicles is turning into a recall; FCA will recall approximately 1.1 million vehicles worldwide to modify the operation of the shifter that has now caused 121 accidents and 41 injuries.

The issue itself is not a fault of engineering but rather design, as the shifter returns to the default center position without giving the driver sufficient feedback as to the selected gear.

As a result, a number of owners have exited their vehicles thinking that they had put the vehicle into Park, while in reality it remained in Drive or Reverse position. The NHTSA has called the operation of the shifter “unintuitive” and had opened an investigation into the issue months ago.

Read more: http://autoweek.com/article/recalls/fca-recall-11-million-vehicles-confusing-shifter#ixzz4DYUXeSCP

With driver reliance on semi-automation systems, system limitations and confusing user interfaces, we can expect to see more cases like the Tesla accident.

Media frenzy and public irrationality

My big worry is that media hype around the small number of accidents will hurt the development of truly autonomous vehicles that can save a lot of lives.

Even in the current state, semi-automation features like lane management and automatic braking can save lives. IF drivers use them as backups.

But we’ll see endless stories about how dangerous automation is. Anything that is “new” is dangerous. It was worldwide news when a Tesla caught fire. Never mind that gas vehicles catch fire much more frequently.

Imagine if we had 24-7 news networks during the rise of aircraft. In the early years of aviation, lots of accidents happened. Every accident would have been covered nonstop.

With much less media scrutiny than we have today, we were able to improve airliner safety. With every accident, we investigated, learned what went wrong and improved.

The NTSB is great at what it does. Although we primarily hear about it in the context of airline accidents, they’re already looking into the Tesla accident.

They provide reasoned analysis, tradeoffs and recommendations. Unfortunately, government, politicians, media and the public don’t work that way. We will see negative hype around self-driving cars as politicians chase votes and media chase ratings.

When it comes to media, only the misses count. If your technology saves 4,999 people, you don’t get credit for that. But you get dinged for the one it doesn’t save.

Developing our safer future requires some reasonableness on the part of consumers, manufacturers, media, politicians, regulators and attorneys. Is that an unreasonable ask?

Why Google+ failed, a product view

vic-gundotra-googleToday is Google+’s fifth anniversary. By most measures, despite massive investments, it was an epic failure.

I’ve been following all of Google’s attempts at social. I knew Buzz, Wave and Google+ weren’t going to work. You can watch me say so in this Bloomberg clip, where I went on against Robert Scoble.

Here are some of the reasons:

A hard line between product and marketing

I’ve talked to Googlers at almost all levels, including several at the VP and SVP level. Some of my closest friends work at Google. What stands out to me is that there is a hard line between product and marketing. Engineers build something and then marketing goes and figures out how to market it.

In the online world — and especially in social — this is a relic and counterproductive. Marketing has to be baked into the product and vice versa.

This is something that Facebook understands at its core. But it’s something that seems to be lost at Google.

People tagging is one of the smartest things Facebook (or any company) has ever done for distribution. (See https://blog.agrawals.org/2007/10/10/the-power-of-the-social-graph/) Is this a product idea? A marketing idea? Yes. Yes. It’s both. And the only way you come up with something like this is having people from a lot of disciplines involved in the product.

Part of Google’s challenge is that it hasn’t had to do a lot of marketing. Its key products — search, mail, maps — have been so much better than the competition that people naturally loved them.

Google did great with Google+,  if you consider traditional marketing. The Google+ ad below was beautifully executed. It should have won an award. But it didn’t move the needle, because that’s not how consumers “buy” social products. (Incidentally, the ads that agencies love — that show off their creativity and win awards — are rarely the ones that are effective.)

Google+’s botched invite process

An invite process is key to attracting users, but it is also important for engagement.

This was the flow when Google+ launched:
  • Rakesh invites Sundar.
  • Sundar accepts invite.
  • Sundar sees nothing, leaves.
  • Rakesh sees nothing, leaves.

(This was the initial flow. It’s possible that the team changed it weeks or months later. I did my testing at launch.)

This is what the flow should have been:
  • Rakesh invites Sundar.
  • Sundar accepts invite.
  • Sundar is automatically connected to Rakesh. (He accepted the invite, it’s logical to connect them.)
  • Rakesh gets an email saying “Sundar has joined Google+. Say hi to him!”
  • Rakesh (who is likely lapsed because of cold-start problem), now has a reason to go back to Google+.
  • Rakesh says “Hi” to Sundar on Google+.
  • Sundar gets an email that says Rakesh has responded on Google+.
  • Rinse, repeat.

Google could also have (with permission) scanned my email contacts and suggested groups like “close friends,” “business contacts,” “family,” “college,” etc. I’d be much more likely to invite close friends than bulk spam everyone I’ve ever interacted with. (a la LinkedIn.)

The Wave invite process was similarly botched. Here was a product designed for groups, but the invite process was such that I couldn’t guarantee my whole group would get in on it.

An emphasis on technology, even when it isn’t needed or is antisocial

In the Google Wave demos, there was a lot of emphasis on the real-time nature of the platform. Changes happened instantly! You could enter a few characters and everyone would see it right away. It seemed that the people who worked on it were very proud of their technical achievement.

It may have been a technical achievement, but it’s not a great social experience. I wouldn’t want you watching letter by letter as I wrote this blog post. It takes some time to form cogent thoughts. I edit and re-edit myself. From the producer side, I don’t want that level of detail exposed. (Especially if I sucked at spelling or typed really slowly.) As a consumer, you don’t really want to sit around and wait for me to type.

Showing instant updates in this context is a bug, not a feature. IM clients don’t show you letter by letter for this exact reason. If we’re showing stock quotes, obviously it makes sense.

Circles was another feature that was technically a differentiator, but socially irrelevant. (And, truly, it wasn’t a differentiator. Facebook had similar functionality, but buried it.) Unlike engineers, most people aren’t highly organized. They don’t group their friends into lists. They don’t actively manage their lists. They don’t want to constantly worry about privacy. Consumers want to make the least effort possible to use a product. Google+ was the opposite of that.

Even the terminology was geeky. +1 means nothing to a normal consumer. I know what it means because I used to participate in Usenet forums. But that’s not common.

Google Photos is exactly on the right track with this. The team understands that people are lazy. Using Google’s machine vision technology to make it easier to find pictures solves a tremendous challenge for people. I love showing friends pictures of kids from birth to now. They can watch kids grow up just by using the scroll bar. Machine vision is also much, much harder for Facebook and Apple to do.

The kitchen sink and the complicated sell

Google tends to have a lot of feature bloat in its social products. They might be great products, but they are hard to explain to people.

The recent social successes have had simple value propositions:

  • Instagram – share photos w/filters
  • Snapchat – share disappearing photos
  • WhatsApp – free global text messaging (way around ridiculous fees for SMS)

You’ll notice Twitter isn’t on the list. It has failed to reach the masses despite billions in free media. There’s no simple value prop.

I have the same problem. I’ve worked in journalism, publishing, telecom, search, local, automotive, payments. I have cross-discipline experience: I’ve done journalism, engineering management, product management, market research, biz dev, UX, corp dev, angel investing and marketing. A typical recruiter (including Google recruiters) looks at all that and says, “Why would I look at this person?”

But sit down with me for 45 minutes and learn how I work and the depth of my thought processes and the usual reaction is, “Why haven’t we hired this person?”

Google doesn’t have 45 minutes — or even 45 seconds to make the pitch to consumers.

Outlook for Allo

I watched the keynote and Allo falls into the same bucket of a complicated sell. Why is a user going to adopt this? Is it for:

  • Tons of emojis. (Piece of cake to emulate.)
  • To play command line games? Zork 2016 (Piece of cake to emulate.)
  • Google Assistant.
  • whisper SHOUT. (Piece of cake to emulate. iOS 10 includes this.)

Better to pick one thing and knock that out of the ballpark. You aren’t going to win FB Messenger users over with emoji. Given Google and Facebook’s relative strengths and weaknesses, I’d bet it all on Google Assistant. Another plus: It adds virality to Google’s other products.

The other key challenge for Allo will be distribution.

WhatsApp built its base outside the U.S. The primary reason people adopted it initially was to avoid paying the exorbitant cross-border SMS and MMS fees. There was an easy, compelling reason to switch.

Facebook Messenger used its insane time-on-site and hundreds of millions of users to build its user base. They had a massive (and personal) friend graph to work with.

So far, I haven’t seen anything from Google about how it’s going to attract users.

Recommendations for product folks and managers

  • Build interdisciplinary teams. The best products come from a team that understands various facets of consumer experience.
  •  Build growth mechanisms within the product experience.
  •  Focus on 1 or 2 easy-to-understand pitches.
  • With more fully featured products, those can be exposed contextually, as people become accustomed to the product. e.g. when Facebook started its move into mobile, they didn’t do big interstitials about mobile. They put a little phone icon next to statuses that were posted from mobile. This subtly introduced the mobile product without hitting people over the head.

Have questions on building products? Hit me up on Twitter at @rakeshlobster or stay tuned for my office hours.

What will the car look like 35 years from now?

We know what self-driving cars look like today. We’ve seen two models so far: the Lexus SUV with a bunch of cameras and sensors on it and the Google bubble car.


But what might they look like 35 years from now? Here are some thoughts.

The obvious design changes will be removing the steering wheel, dashboard and gear shift. But those are some of the least interesting.

Cars today are designed for human drivers, safety and convenience. Over time, the first two become unnecessary and the convenience becomes dominant.


There are a number of features that are necessary for driving that can go away:

  • Driver and passenger side mirrors and the rear view mirror. Nothing to see here. And getting rid of the exterior mirrors will make the cars more fuel efficient.
  • Windshield wipers. The car doesn’t need these to see. (But there are other reasons to keep them — see below.)
  • Windows. The car doesn’t need them, but also see below.
  • Turn signals.
  • Dashboard with gauges.

Some things can’t go away, not because the car or passengers need them, but for safety of others. We don’t really need headlights. But pedestrians do. However, the headlights can remain off most of the time and be turned on when there are people or animals around. This will dramatically reduce light pollution. (Lack of signals have already caused problems for humans; the blind can have a hard time with hybrid and electric vehicles because they are nearly silent.)

bubble car


We’ve added a lot of safety features over the years:

  • Airbags
  • Side impact door beams
  • Seatbelts
  • LATCH anchors for car seats
  • Crumple zones
  • Bumpers

These add substantial weight to cars.

With self-driving cars, car accidents will be incredibly rare events. The biggest safety feature will be the lack of human drivers.

Make driving safe enough and you can get rid of that weight, making cars more fuel efficient.


Sure, we’ve added radios, CD players, rear-seat DVD players and cupholders. But a self-driving cars will provide a whole new dimension of convenience.

Instead of having the typical front-facing seats, we can have different seating arrangements. Maybe a table for playing games, cards or just talking.

Recliner seats or beds for sleeping. Reading lights that dim the rest of the cabin.

Air travel is a model to look at: from the perspective of the passenger, an airplane is a self-driving transportation vehicle. We could have a big screen display for watching movies with thousands of options. Cameras for teleconferencing. Better, more immersive sound systems.

We could have the equivalent of Airshow: maps and stats on the journey.


These features could be segmented as airplanes are. Vehicles that are basic for short trips and luxury vehicles for long hauls. (Of course, you could order these on demand for a particular trip.)

There are some things that the car doesn’t need, but we might want to keep for humans. Windows and windshield wipers are two of them.

We still have windows on planes because people want to be able to look out. (Cargo planes don’t have windows because it is more fuel efficient.) Likewise, we need to provide visibility, especially on scenic roads. But we can improve these, too: windows and the windshield will have the ability to become opaque. This is better for having sex and watching movies. Or driving on an urban blight road full of billboards.

Now all of this will take a long time. The average vehicle on the road today in the United States is more than 11 years old. If we’re looking at individually owned vehicles, it would take 20 years or more to turnover the fleet. But this should be accelerated by purchase of self-driving cars by companies like Uber and Lyft for on-demand service.

The driving and convenience features are easier to change than the safety features.

Having a self-driving car on the road without a steering wheel is fine, because other vehicles don’t rely on it. We can’t get rid of turn signals because other cars need to know which way the self-driving car intends to go.

The safety features will need the longest to get rid of. If humans can cause accidents, we still need to protect the occupants of the self-driving car. This also affects the convenience features; we can’t have people standing up unbuckled if there’s a chance that the car will get hit.

Regulators and public fear will also play a role in further delaying the removal of outdated safety features.

All of these changes can’t happen fast enough for me.

Read my post on how cars have changed over the past 35 years.