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.
Instructions for disabling read receipts came out almost as quickly as the announcement.
Full disclosure: I own a small number of Twitter shares.
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.