Not too long ago, Joel Spolsky’s blog post about architecture astronauts hit my various consumption feeds, and it serves as a good reminder that, as fun as it is to make fun of product managers (and it is a lot of fun), they’re also probably the most important people in software development. That may seem a bit over the top, seeing as how QA engineers are the ones who ensure that what’s shipped actually works, developers like me actually write the applications and services in the first place, and then there’s the operations teams that build and run the production infrastructure the code actually runs on. It sure sounds like there’s a lot of other people with a lot more direct connection to the actual engineering bits. The truth is, we’re all important, but without good product management, it’s entirely possible for everyone else to do a perfect job…and the release still fail.
In Spolsky’s article, he focuses on Napster as an example, which for the kids reading this, was a service where you could search for songs other people had on their computers, then listen to, and in fact download for yourself, from those other computers. It was eventually shut down because of the massive copyright violating that it was pretty much exclusively used for. (As an aside, if we’re ever going to drop the streaming everything and owning nothing and going back to downloading and installing software, can we bring BitTorrent to do it? That was awesome.)
Reading the article, and you see the break between people excited about the technology (“peer-to-peer all the things!) and people who understand about building products (“type the name of a song into a box and start listening to it”). The problem for the first group is that it’s entirely possible to build a technically sound product that’s nobody wants to use.
Here’s a real story from my career as an example. I used to work for an email marketing company1. We wanted to build an add-on for integrating with social media marketing (specifically, Facebook, Twitter, and Instagram). The “big” part of this, the showstopper, the thing we emphasized in demos, what we thought would be the absolute money-maker, was the ability to run email marketing campaigns through Instagram.
The way it worked was like this, customers would give users the ability to enter both their email address and Instagram handle into a form (both for capturing consent for the marketing, and because we needed to associate the 2). Then, our customers could configure a campaign in the email marketing platform, identified by a hashtag on the Instagram post. They could then configure a additional tags to include in the post to trigger specific messages with content from the post and the user who triggered it (more on that last part in a second). This could include their Instagram handle, the image from the post, etc.
The company would then make an Instagram post with the campaign and message trigger tag in it, asking users to comment with the campaign hashtag for more details, special offers, whatever. Users who opted-in to the marketing program and left a comment with the tag would then get an email about that product a follower on Instagram just explicitly expressed interest in.
These messages had something like $1-$2 of revenue per email sent. For contrast, a “batch and blast” (emailing whole mailing lists) would typically average about $.08 per email sent. This thing was a revenue-generating machine. We gave it the greatest amount of support afterwards, with us adding features like a plain generic sign-up form template where all our customers had to do was provide a graphic, put the program descriptions in their own words to keep branding consistent, and put in their brand colors), and we’d give them a form they could link to for sign-ups. We built in an automated reply function so if someone who hadn’t opted into this program tried to trigger a message, we’d prompt them to sign up. If someone signed up, we checked for any message triggers they left recently and sent the message anyways. We did everything we could think of to make this as easy to use and run as possible.
And in the end…hardly anybody used it. There was 1 craft supplies company that ran a campaign for a couple of months (which 1 of our professional services associates and I pulled the above data for in order to make a case study/customer success story), but quit because they said they didn’t have time to put in the work, despite the money this program made, and us showing the message metrics for these emails in the console where they managed this program. I spent months working on that functionality. In the end, it had the exact same number of users as if I never worked on it at all.
That’s why product management is important. Their whole job is to understand the customers, the industry, the problems customers are having getting things done, what they’d appreciate software doing for them. So they can realize that yes, running an email marketing campaign through Instagram is absolutely really freaking cool, that’s also something that takes time and active management which is something our users apparently want to avoid. They’re the ones to tell you that the tool you also worked on, to sync their mailing lists with custom audiences on Facebook in the background (and later Google), for ad targeting, was going to be a better use of your time, Especially the ability to create a lookalike audience from your segmented customer data. Yes, that didn’t have the fancy dashboard, and was basically a background sync job that doesn’t look or sound cool. It was still going to be the most-used portion of this add-on, and the thing that was going to get people to agree to pay us even more money just so they could use it.
The thing that made this article hit home is the Solid project. Created by Tim Berners-Lee. It’s another technically fascinating project intended to help re-decentralize data sharing across the web. The idea behind this project is that people would put their data in pods, and then grant access to other companies to the specific pieces of data users wanted to give them. The protocol and spec behind the pods is currently in the process of becoming an official W3C standard, which is nice, since it would make Solid something similar to email and RSS where anybody could build something that writes and reads it, and it could be used by anybody else even if they’re on a completely different application.
I love the idea of this project. I want this project to succeed. It promises to give individuals control over their data, and make that data independent of specific apps, so why am I so sure that it has no apparent product management despite being technically fascinating? Because it’s been around for over 5 years, and odds are most people haven’t heard of it, despite being spearheaded by the guy credited with inventing the World Wide Web. Berners-Lee built a company around it to help provide commercial support for the project, called Inrupt, which is focused on selling storage solutions using this protocol, which is, in my opinion, the least interesting part. The interesting part is that every file saved on this server (and raw data like address and birthday is saved as a file as well) has a corresponding .acl version, which holds the access control list for that file. But you when launch a local instance of the main community server implementation, doesn’t let you do CRUD operations on the data, like upload files to this handy-dandy “pod.” That means I can’t get the data in there so I can set and manage permissions just how I want to. The server just implements the spec, content management can be done via 3rd party app.
Let me explain that experience (and this is the point where I dropped off doing anything with Solid because I can’t even experiment with a pod on my laptop before paying for a server). You have to go to a completely different URL, give it the URI to your data store, give it permission to read and write to your data store, and then you can manage the files on that store via an actual built-for-Solid-app. That just feels sketchy. And we’re hoping non-technical people are going to be up for this? There’s a great blog post that I came across from another developer who wants/wanted to believe, but was left unsatisfied. Check out the comments too – there’s an equally great long comment from someone involved in the project with more details.
It seems cliche to say that everything we build should be treated as a product, but if you want people to use the code you write, somebody needs to be thinking about said users and their problems. Oh wait, that’s literally a product manager’s job! That’s the kind of focus that keeps software development from going down rabbit holes of things that sound cool and demo well, but don’t actually get used.
By the way, it’s tempting to think product management is just getting feature requests, copying and pasting those into tickets, and then telling developers to “get to work.” I’m guessing that’s why people think that it’s possible to build (and try to launch) technical products without any apparent product focus or product messaging. The problem is that “build it and they will come” only works for Hollywood movies.
This got hammered into me during college, and I’ve never seen any evidence to the contrary – “software development is about solving problems, we just happen to use computers to do it.” The best software makes the stuff you’re already trying to do better or easier. It takes a lot of industry understanding and context to turn the random things users ask for into “here’s the underlying issues people who we want to sell software to have, and here’s what a thing that makes their lives better looks like.” Filling in the blanks of that sentence correctly is hard, and it’s why companies pay people to spend their entire workday figuring that out and telling the people responsible for building solutions.
- It was shut down after it got bought by a company that got bought by Oracle, who decided that it didn’t need 2 email marketing products, and terminated the one that people chose every time they had an option between the 2 in favor of the one Oracle made. ↩︎