Earlier this year, I attended a pitch night at my local coworking space. One of the teams that presented is working on a product to help prevent driving while drowsy. It’s a noble goal — drowsy driving can be as dangerous as drunk driving. Like drunk driving, people aren’t very good at self-evaluating their fitness to drive when they’re sleepy.
But as they talked, I sat there going “no. What are you doing?” They talked about learning who the driver is and establishing a baseline of their attentiveness to measure their drowsiness. All kinds of cool whiz-bang stuff. And maybe someday they’ll add some haptic feedback to the steering wheel.
I suggested that they target diabetics as a first market. Hypoglycemia is dangerous, too, and it’s an easily-defined audience, which helps in initial go-to-market efforts. When I talked to them after their presentation, they started talking about maybe adding blood sugar sensors.
No. Just no. I asked them if they’d considered what storing data might mean. It creates a liability for the driver in case of an accident. It could be used by insurance companies to change rates. It could be compromised and used for something else.
Using the latest tech is neat, but only when it makes sense. And sometimes, the more you add, the worse things get.
Google has a problem. Well, Google probably has many problems. But in a recent Ars Technica article, Ron Amadeo points out a particular problem: shutting down products frequently is harming the Google brand. Google killing off products is nothing new; some people are still mad about the death of Google Reader nearly six years ago.
Are we reaching an inflection point, though? I don’t know. I lived in fear of Google ending Google Voice, but that managed to survive despite languishing for a long time. But when I saw that T-Mobile offered a service that (somewhat poorly) replaced the Google Voice features I actually used, I switched. With the exception of Reader, none of the product retirements have affected me personally very much. I wanted to like Google+, but it never caught on. I liked iGoogle, but once it went away, I was fine without it.
Even though I haven’t personally been affected too much by Google’s ruthless culling of the portfolio, I’ve found that I’m becoming more likely to consider alternatives to Google services when they exist. Certainly if I were running a business, I would be very wary of relying on any software-as-a-service (SaaS) offering apart from the Gmail/Google Drive core.
I get that Google is trying different things and there’s a lot to be said for cutting off a project (particularly a popular one), when it’s not meeting whatever measure of success you set for it. Doing this in public is even more challenging. I don’t think this will end up causing too much harm to Google, despite mounting dissatisfaction. As long as search (and ads, of course) remain strong, these consumer services exist only as experiments in finding new ways to get ads in front of eyeballs.
What does concern me is Google’s ability to suck the oxygen out of the room. By creating a reliable, easy-to-use product, Google can eliminate the competition. Then when they shut it down, destruction is left in the wake. I’m thinking in particular of the diminished role of RSS after Google Reader’s shutdown and the drop in instant messaging (at least among my friends) after Hangouts removed XMPP support and essentially went on life support.
Neither of these can be entirely attributed to Google. The rise of Facebook as a behemoth helped, too. But the fact that Google weakened the ecosystem made it easier, I’d argue, for Facebook to swoop in and finish the job.
All told, I think Google’s product retirements are a good thing, as dysfunctional as they may be sometimes. They clear the underbrush of product offerings like a forest fire. Some of the strongest survive and the rest is made ready for new life to spring forth.
“It’s on the roadmap” was a common expression when I worked in customer-facing roles. That statement is a delightfully vague response to feature requests. It might mean “it will be in the next release.” More often, it was as close as I could get to saying “yeah, there’s no way in hell we’ll ever get around to implementing that” without getting myself in trouble. Cowardly? Probably. But at least it was tactful.
At a previous company, we did actually have a product roadmap. It looked forward through the next year, broken down by quarter. The first quarter was generally pretty accurate, even if some of the work slipped a bit. The second quarter was okay. The third and fourth quarters? Well they didn’t really reflect anything approaching reality.
But for me, it’s all about how the road map is used. “Road map” is a pretty lousy term, when you think about it. I spent a lot of time looking at road maps as a kid (I’m so cool!) and they almost always gave an accurate representation of what was coming a mile or a hundred miles ahead. Product road maps, if taken that way, lead to lies and broken promises.
For me, a better framing is a product forecast. When the National Hurricane Center forecasts hurricane tracks, they don’t just draw a line and call it a day. The forecast graphic shows an area of uncertainty that expands with time. When a storm is a few hours offshore, you can generally be fairly certain where it will make landfall. When it is days away, the potential landfall area is much larger.
Example hurricane forecast graphic from the National Hurricane Center
The analogy isn’t perfect, of course. Products can pivot much faster than hurricanes can. And storms are things that just happen to us, whereas the product is something we can consciously effect. But in general, I like this idea. In the short term, you know what you’re working on and what you’ll be able to deliver. Beyond that, you know where you’d like the product to go, but something may happen between now and then to change it.
I like the “Yes, No, Maybe” model that Ben Balter wrote about last year. In his post, Ben limits the roadmap to the next three months and categorizes work as “yes we’re doing that”, “no we’re not doing that”, and “maybe, but we need more information”.
The advantage of the three-month window is that it prevents the roadmap from becoming a giant lie. But extending a product roadmap (or forecast) beyond three months helps give some context to the work being done in the short term. People benefit from having a longer-term vision, even if they change direction before they ever reach it. Forecasts are wrong sometimes, but they represent the view of the future from the best information available at the time.
Do you need a product owner? Many organizations seem to think so. Scrum.org says a product owner is “responsible for maximizing the value of the product resulting from the work of the Development Team”. That certainly seems like an important role to fill. But Joshua Kerievsky wrote in 2016 that customer-obsessed teams don’t have product owners.
Having a formal product owner, he argues, means engineers merely implement. They are absolved of responsibility for the final product. “Massive technical debt, poor reliability, ugly UIs, bad usability and new, barely used features” are due to having product owners. Companies that produce excellent products send engineers out into the field to learn from real-life customers. This means there’s no need for a product owner because everyone is a product owner.
Kerievsky is right, in part. Putting all responsibility for the product on one person is a recipe for disaster. Customer focus is not something you can bolt on at the end. If the people building the product don’t have the customer in mind as they build it, the product will reflect that. Regardless of what the product owner does.
But responsibility and sole responsibility are not the same. Engineers need to think of the customer as they build the product. And the product owner is responsible for keeping the engineers focused. The proper role for the product owner is not setting product direction, it is setting culture direction.
As Eran Davidoff wrote, we are all product owners. Not just engineering teams, but everyone in the company. Marketing, sales, and everyone else must focus on driving impact, not completing tasks. Positive business impact means understanding the customer and meeting their needs. Sometimes the customer is an internal customer, not the end customer. But meeting the needs of internal customers can indirectly help the end customer.
Ultimately, the job of the product owner – be it an internal or external product – is to make sure the measurements match the goals and that the goals match the mission. After all: we get what we measure.
Snapchat’s founder announced on Friday that the company is working on a new, non-software product: sunglasses. Set to go on sale this fall, these sunglasses will include a camera that, when activated, will record 10 seconds of video. Presumably, this video will be posted to Snapchat by way of the user’s phone.
Some of the reaction I’ve seen so far is pretty predictable: “it’s like Google Glass, but less featured!” and “what a great way to announce that you’re a d-bag.” Haters gonna hate, as they say, and I’ll admit that the design is not my style. Still, there are reasons to believe Snapchat’s Spectacles will have the sort of wide consumer adoption that Google Glass never did:
Price. At less than one-tenth the price of Google Glass, it’s much more affordable. The price is in line with normal sunglasses, for those of us who don’t buy our sunglasses off the spinny rack at the drug store (full disclosure: I buy my sunglasses off the spinny rack at the drug store).
Branding. Oh sure, Google had great brand recognition when Glass launched. But Google’s brand is more about utility. Snapchat is about social. And this lines up well with the respective eyewear, but I think the fact that Snapchat is a social media platform, not a “know everything” platform helps in this case.
Obviousness. Both Google Glass and Spectacles are pretty obvious externally, but Spectacles will apparently have an LED light to indicate when it was recording. The fact that Spectacles are sunglasses, not a fixture on general-purpose glasses, means that some of the more obvious privacy concerns (particularly bathrooms) are avoided because people probably won’t be wearing them inside. Plus the limited duration shortens the window for privacy violations. It’s more “I have my camera ready to go” and less “I am recording your every move.”
Simplicity. Yes, Spectacles have very limited use, but that also means they’re really easy to use. I haven’t used Glass, so I can’t speak for the ease of use, but it’s hard to beat “push this button.”
None of this is any guarantee that Spectacles will be a success, of course. It will be interesting to see how this affects Snapchat usage. Anecdotally, while I have many friends of a variety of genders, ages, and interests on Snapchat, it’s a small group of mostly twenty-something women that post stories (perhaps there’s greater usage 1:1?). There’s a lot to be said for being able to share your experiences from your own point-of-view, so now we’ll have to see what Evan Spiegel and company can do.
Not content to leave the potentially user-hostile decisions to Apple, Twitter announced last week that they were adding read receipts (among other features) to direct messages. Annoyingly, this is an opt-out feature. Twitter is once again adding a feature no one wants while ignoring the real problems of abuse on the platform.
I’m no product management expert, but I know there are times when you listen to your users and times when you don’t. “I want this thing” is a good time to not listen to your users. That’s not to say you ignore their wishes entirely, but you can build a product that people like even if they don’t realize that’s what they want at the time. Apple has had a fair amount of success with this approach.
“This thing is a problem” is absolutely something you listen to your users about. Particularly when prominent people end up abandoning the product. While Twitter has given lip service to the harassment problem, it does not appear to have taken any meaningful steps to address it. In fact, the read receipts can bolster harassment.
Before the addition of read receipts, harassers would have to guess if a direct message was read or not. With read receipts on, there’s the immediate satisfaction of knowing your message got through. Even setting harassment aside, read receipts just reinforce the cultural demand for immediacy. I’m fairly connected digitally, but I don’t see a benefit to read receipts. I’ll probably respond to a message quickly, but if I don’t then that’s my decision. I don’t need the platform insinuating that I’m ignoring someone when I’m really just trying to keep my children from tearing the house apart.
Last week, Apple announced the latest version of their flagship product. The iPhone 7 will begin shipping to customers on Friday and it will be the first to not have a headphone jack. The 3.5mm jack, which has been around since at least 1964, is the standard appearing on computers, music players, phones, some airline seats, and more. The standardized technology means you can use one set of headphones in any of those places without hassle (except for detangling the cords, of course).
But no more, says Apple. They used “courage” to describe this decision, a phrasing that has been soundly mocked. Courage probably isn’t the right word, but it’s certainly bold. This is a big risk that Apple hopes lays the foundation for additional changes that will lead to an inarguably better product. Of course, it might serve to further put the brakes on plateauing sales and a growing sense of meh.
Apple supporters are quick to point out that the doomsayers were wrong about Apple’s decision to remove floppy drives, CD drives, and ethernet ports. This feels like a different scenario, though. In previous cases, there was always something better to use instead (though I still wish the MacBook Pro I use at work had a wired ethernet port). Particularly by the time the optical drive was killed, USB drives and network services met the needs of the average consumer much better.
What’s the better option for the iPhone 7? Purchasing headphones that can only be used with Apple products, that require charging every few hours, that can’t be used while the phone is charging without an additional adapter? Will the technology used by these wireless headphones avoid the lag and disconnection issues that can frustrate Bluetooth device usage? Will noisy spectrum become an issue in crowded spaces like buses and subways? Will people be able to avoid losing them?
Apple’s previous removals proved to be successful enough that other manufacturers followed suit. But that success was possible in part because better standard solutions were available. This time, there’s no standard; it’s Apple or nothing. I don’t see that there’s a compelling enough story for the average consumer to support this as a long-term change. I’m no soothsayer, and I could end up complete wrong. But I bet Samsung really wishes they could have a do-over on the Galaxy Note 7’s battery: it could have been a great chance for them to take some of Apple’s market share.
I’ve spent a lot of time in the past two years researching and thinking about technical debt. In most of that time, I’ve thought about it as something that’s an implementation detail of the code. It’s probably fair to keep it defined to that context, but that leaves a lot of places for debt to be introduced before any code is ever written.
A recent post on the Instigator Blog discussed the concept of “product debt” (also referred to “design debt” or “user experience debt”). One of the key indicators of this sort of debt are differences between, for examples, different forms within a product. I’d argue that the ability to reuse documentation between products (e.g. installation instructions) is an inverse measure of debt.
The post is a great introduction to the concept, but as I re-read it, I realized that I didn’t like using the term “product debt” for what the author describes. Most of the discussion is around user experience design. While UX is obviously very important to successful products, it’s not the only consideration. Similarly, there are other kinds of design apart from UX design.
I have given the matter some thought, and I’ve come up with the start of a taxonomy for debt. “Why create a taxonomy?” you may ask. Firstly, because if we can use a common vocabulary, we can communicate more clearly with each other. Secondly, because having a way to categorize debt can allow project/product managers to manage debt payment. Finally, it could be a launching point for academic studies of debt in order to better guide the debt payments in the second point.
So here’s a first draft of a debt taxonomy. The categories below are all components of a total product debt.
Technical debt. This is the debt that occurs in your code as implementation details.
Architecture debt. This is the debt you incur from design decisions, including the API.
User experience debt. This debt is basically the debt described by to in the linked post.
Documentation debt. This debt accrues when your documentation is missing, incorrect, or unreadable.
