Product Management: How and why ‘technical products’ are different. Or are they?
Although customers interact with ‘technical’ products differently, you should manage them the same way. Here’s what I’ve learnt about being a product manager for ‘technical’ products.
We’ve all been there. “Sam focuses on technical products because she used to work as a developer. Ben however likes speaking with customers so he does the UI products.” Products are carved up and the product managers go along with them. The same rules don’t apply to ‘technical’ products. Developers treat product manager differently because of how they feel they understand technical subjects. When a ‘business’ product manager works on a ‘technical’ product, it can make him or her feel uncomfortable. This needn’t be the case.
What is a ‘technical’ product?
Not only are business products becoming more connected, consumer ones are too. My login to Medium is actually via Facebook, last.fm links with my Spotify account, Europe is forcing banks and payment providers to connect to each other using open standards.
These are all powered by APIs.
APIs are the classic technical product. They require an extra step for the customer to do business with you, often with the help of a developer. Unlike a user interface, the average person can’t just ‘have a go’ at designing them. Also unlike UIs, there are far fewer resources on the web about designing good APIs.
There are other examples of technical products: features which handle large amounts of data, things requiring JavaScript or SDK integrations, and also initiatives like supporting Google AMP could all be described as ‘technical’.
I’ll stick to APIs here as they’re probably the one that you’ll come into contact with the most.
Integrations cost your customers
Technical products are often defined by need for integration. Integration is a cost and burden for the customer: They need to understand why it’s worth their time integrating. They need to put it into their roadmap. There’s a risk that an integration takes longer than expected or knocks something off the development schedule that they have promised their customers.
These are all costs that the customer bears, not you, and costs that your sales team need to justify to their clients. It had better be worth it.
Changing your products is also more difficult here: you can break existing integrations by changing an existing API. Make non-breaking changes and customers often either do not use the extra features or remain on an older version indefinitely.
Sales and management understand technical products better than you think
Start with speaking to sales and management. They may have sat on the phone for hours explaining to a customer why they need to integrate your API. Integrating an API involves commitment and sales will at least know who asks the most questions, who had the biggest problems with integration.
What they won’t know is if it was worth the time for your clients. Maybe customers integrate then don’t get any value from the product?
Ask sales and management to explain the value of the API to you and see if it matches your experience. Ask customers who have integrated if it was worth their time. If you find they don’t use it, great — you might be able to save money by turning it off.
But we keep secrets
Sales and management probably know who the customers are and how much money they make. They probably also know who earns you money or at least who uses parts of your UI (via Google Analytics, for example) or even they have detailed information through something like SalesForce — at their fingertips.
Getting information about API usage can be tricky: logging is often difficult to get; hidden away in log files on servers, API keys hide who users really are or make looking them up sometimes impossible.
Attributing money or importance to clients’ API calls is another challenge. Users who hammer an API may be of little importance to your business; whereas those who lightly tap it once a week might be vital. This is very different from users interacting with a UI, as they need to spend their time and attention (i.e. money) on your product. Many APIs however are simply integrated and then forgotten, leaving cheap computers to do all the attending.
Bake analytics in
Here the key is to design APIs and technical products in such a way that it’s easy to see who is using what. Make sure that support staff, sales and management can easily see this information. Design this in from the start and think carefully about defaults.
Defaults can skew your understanding of a product. If your API gives too much information with one call, you will be:
a) collecting all this data, perhaps from a range of sources, making it inefficient (but developers will be able to tell you this); and
b) not understanding what people really want as they might want any one of the bits of data you return.
Spotify, for example, has two ways to call their API: one for getting information about an album, another for getting the tracks of a particular album. Could Spotify simply give you the tracks when you ask for the album? Of course. Why don’t they? Well it could be because they want to be able to differentiate customers who are interested in albums and those interested in tracks of albums.
Don’t get developers to do the dirty work
It can be easy to leave the design of an API or other technical products to developers. They do after all sit there doing technical stuff all day and integrate with many many products. This would be a mistake.
Developers have great ideas and their job is to solve problems. They will be invaluable to any design of a technical system. However, they are not the customers. They will have biases due to their own technical experiences, the way that they develop at your company and what they think of the customers.
I was once product managing a system for downloading large lists of items users can buy online. This would be a ‘technical’ product as customers need to integrate. We wanted an easy way for users to download lists via the user interface. We offered two types of downloads: GZIP and ZIP. I didn’t specify which type of download and our developers assumed GZIP because that’s what they know and feel comfortable with on their Linux development environment. Customers however used our UI on a Windows or a Mac or at least some form of desktop UI which will always support ZIP, making that clearly the better choice. On the day we released the feature, the first support call we got was, lo and behold, for us to change to ZIP.
Not all API users are technical
Integrations are becoming more common-place. More software and physical products can be connected to other data sources and devices. Excel even supports easy integrations with REST APIs and a range of other online services.
This moves APIs beyond the realm of developers and more into the world of ordinary users. When all Excel users can use an API, is it really such a ‘technical product’?
In about 10 minutes, I managed to connect an Excel document directly to Spotify to query artists with the keyword ‘queen’ using the Spotify Web API.
Product Managers are different but their aims are the same
Overall Product Managers all have the same aim: understand the customer and design products that solve their problems. This goes for ‘technical’ as well as ‘non-technical products’.
Your customers are often the same and earn money in the same way. It’s all too easy for Product Managers so start relaying on developers to come up with the solution or to take on the role of a developer rather than a Product Manager.
Save yourself the hassle: don’t differentiate between technical and non-technical products, or for that matter technical and non-technical product managers.
Conclusion
- Product Managers who do not have a technical background have a lot to offer with standard product management techniques.
- Learn how REST APIs work. They intuitively make sense and most users can play with them using a browser extension.
- Think of how to monitor the usage of your ‘technical’ products from the start.
- Consider how you can avoid making breaking changes in the future.
- Don’t forget to speak to your clients’ developers. They’re the key to understanding integration costs. If too expensive, clients won’t integrate and you’ve wasted time developing your product.
Sources:
Snooker image: https://en.wikipedia.org/wiki/File:Shutter_speed_pool.jpg
Laptop image: own work
Excel screenshots: own work screenshot from Excel 2016
