Building For Builders: A PM’s Guide to Developing a Platform
Slate launched their redesigned website last month on an open source content management system, Clay. As the product manager for Clay, I found working on an open source platform has an unexpected set of liberties and limitations. We define what the platform can do, yet have to tread carefully to not cause disruptions or make choices that limit options for our partners working with a different set of use cases.
On one level, working on a platform just takes good execution of basic product management principles: be an advocate for your users, prioritize problems and not solutions, etc. But here are the key pieces of advice I’d emphasize to a PM starting to work on a platform:
1. Put yourself in your fellow PM’s shoes.
It’s a slight twist on understanding your users. An easy trap to fall into while building a platform feature is that it only serves your one specific use case. When considering a feature, ask yourself if multiple teams can tap into it. Can it be combined with features already there? Can another company on your platform with a slightly different workflow integrate it or find it useful? Don’t be afraid to reach out and ask. Something the team at Shopfiy has been saying for years and I don’t miss an opportunity to repeat is, “All platform features should be like Lego blocks.”
2. Be technical.
Understand all of the technical components of the platform and how they interact with one another. This will help you discern legitimately cool “wouldn’t it be cool” ideas from “wouldn’t it be fun” ones. You can have a technical understanding of your platform without writing code, understanding how data flows will get you to where you want to be. Saying it goes from the client to the server isn’t good enough. Which front-end framework do you use? How and when is data submitted? What repos does it touch? What is the data type when it’s saved to the database? What kind of database is it? Why did we go with that kind of database?
3. Expect it to be a little harder.
Because of the limitations I mentioned earlier, expect platform solutions to be a little harder to get to. The key thing is to push through. There have been many occasions when we’ve discarded the fifth idea for a solution and the sixth one to be the golden ticket. I’ve found that platform features take more discovery time, you’re not only weighing trade-offs for end users, but developers and other implementations of your platform too.
4. Remember developers are also your users.
When we asked in a survey to our developers what their biggest pain points were, I was surprised to hear the answer to be too general error messaging. I had worked with developers on several non-platform projects and consulted on many others, but I’d never heard this come up. It turns out that just like users do on consumer-facing apps, developers found creative ways to circumvent the problem and built that into their workflow. We now solicit feedback more directly from developers and don’t assume that they will open a Github issue every time they run into a problem (which is still the best way to get your concerns addressed).
5. Avoid baking in team workflows.
One of the most common feature requests I used to receive from editorial teams was around workflow. Editors wanted a streamlined way to see what was in the works. The copy desk sometimes wasn’t sure if feedback had been addressed before publishing. In short, they wanted Clay to enforce a workflow. Luckily, a few wise developers talked me off this ledge.
I spent more time with these teams to understand their workflows and found that the exchange of drafts between writers, editors (sometimes several), and copy-editors was not consistent from team to team, much less from site to site. The requests from writers also presumed that Clay is an article creation tool when one of our mission statements is that Clay is content-centric, not article-centric. Clay powers homepages, section fronts, interactives, ecommerce, and more. If we had implemented an explicit workflow, we would spend countless hours patching edge cases. Instead we identified the two pieces of information that everyone was looking for, who made the last edits and how long ago. After we made this easily accessible, the feature requests for special statuses and checkboxes slowly disappeared.
The point is, workflows between teams may seem general, but are very esoteric in ways that users don’t see. Focus on the information the user is looking for rather than what they want to do.
