There were tears, there were nose boops, there was steak, there was peanut butter whiskey.
Truman had just beat lymphoma in June, when he first went into respiratory distress from congestive heart disease. He, Erica and I have been fighting that and pulmonary hypertension since. It’s a balancing act between being able to breath and kidney failure.
He started eating less this past weekend, stumbling around, then not eating anything. Then yesterday he had a grand mal seizure in the yard.
He was telling us it was time to go.
“Peace and long rest for weary old heart and head and limbs, and eternal sleep in the earth I have loved so well. Perhaps, after all, this is best.” – Eugene O’Neill’s will for his dog
I know he’s in a better place. Digging (and eating) in the dirt with abandon on fully functional knees. It’s always “Truman weather” (cold but not freezing, sunny and never raining), and his parents let him eat all the street pizza and chicken bones he can find.
If you can get past the “one weird trick” algorithm, YouTube has a decent collection of historical aerospace films. In my Apollo collection is this gem of a video that I’d love to get more details on.
It shows an early concept for getting the LEM from behind the command module to the docking port. Instead of the transposition, docking and extraction maneuver we’ve come to know, it shows a set of arms physically rotating it into position. The arms are jettisoned when the LEM descends to the Moon, and the LEM docks as we came to expect it when it returns from the surface.
LEM after S-IVB jettisonWave your LEM in the air like you just don’t care!
It’d have to require cooperation and interfacing between both North American – maker of the Apollo Command and Service Module which is where these arms connect and where the rotation mechanism seems to be — and Grumman who eventually won the contract for the LEM and would have to handle the linkage of the arms and the stresses imparted via the arms during launch and the rotation.
Was this an actual early planned concept by the engineers later shaved for weight savings? An artists concept early in the program when so little was known? The film is undated so its hard to pinpoint. I’d love to learn more.
It is well and good to have the government handle large externalities, or quantifiable ones. I should pay for the wear and tear my car puts on the road. I should pay for the carbon impact of my emissions. But by expanding government’s scope to handle small externalities, and unquantifiable ones, they’ve created a system where few things are doable as-of-right, everything is up for debate, and people are incentivized to exaggerate or even fake grievances.
“Winners will always seek to entrench themselves, buying up competitors or starving them of resources and seizing control of political power and forums for speech and debate.”
“It’s long past time to replace the idolatry of innovators with a reinvigorated respect for the rules and the umpires who enforce them.”
My favorite 1:1 conversation continuer and relationship builder question is “Tell me more?”. When you get those single sentance answers to a question, or your counterpart comes to the end of a thought.
“… and the sellers really enjoyed the feature.” “Tell me more?”
“I really liked what you said in your top of minds e-mail about dealing with outages.” “Tell me more?”
“I’m interested in doing more strategy work, but I don’t have the time.” “Tell me more?”
You have a Google Sheet, you’d like a (or all) row(s) to have a date-stamp added whenever an edit is made. That way others you’re collaborating with will know when the row, or the sheet itself, was last updated at a glance.
If you search for this, you’ll find something like this but it needs some tweaks. This is the third time I’ve searched for it, found it, and then had to re-learn what needed tweaking for it to work for me. So I’m saving it here for my posterity and note-keeping.
function onEdit(e) {
var sh = e.source.getActiveSheet();
if (sh.getName() !== 'Sheet1' || e.range.getRow() == 1) return; // Skip if we're on another sheet, or not the header row
sh.getRange(e.range.rowStart, 3).setValue(new Date()) // Put the date in column 3
}
I’ll give you a brief background about myself and my work on platforms.
Then we’ll ground ourselves in what a platform is, as it can mean a lot of different things to a lot of different people.
From there we’ll tackle two of the many things that make platform product management different from other products: The customers, and the interfaces
Who am I?
Let me give you a bit of background about myself. I’m originally from St. Louis. Like many product managers, I’ve got a twisty/windy career path. It started with degrees in journalism and media management from the University of Missouri.
From there I moved to Atlanta and worked at Cox Media Group in software engineering on content management platforms. As a senior engineering leader I got exposed to a lot of our internal customer struggles – be it journalists, sales people, or developers at the local properties trying to build their own applications atop the CMS.
After that I moved to Kabbage, a fintech business lending product. I led an engineering team building an internal customer service tool that served multiple teams, as well as several international banking partners using Kabbage’s lending platform. They wanted to integrate the tools loan data and operations into their own local customer service and collections tools. That way their agents could act on their customer without having to bounce back and forth between multiple systems.
From there I worked at Pindrop on a cloud based voice security product aimed at financial and insurance call centers. The product took in voice and touch-tone data, performed real-time fraud analysis and provided programmatic updates to fraud scores. All of this had to be deployable, configurable and manageable via APIs.
This history of engineering leadership, close interaction with customers, and a lot of platform and API work, put me on a path to my current role at Square. Where I work with several product teams across our Payment Platform focused on payment acceptance.
The platform is used by developers inside and outside of Square to build applications for sellers. Last year, we helped sellers moved more than 100 billion dollars in payments volume. Card not present payments, ACH payments, card present payments — on our magstripe, EMV, or beautiful all-in-one terminal hardware. All done via REST APIs, browser and mobile SDKs.
In the nearly four years I’ve been at Square we’ve grown rapidly, and continue to grow. We’re looking for more product managers to help us make our platforms and products more remarkable – head over to careers.squareup.com if you’d like to learn more.
What is a platform?
The fundamental concept of a platform is sharing.
Shared data, shared experiences, shared operations that in turn create shared value for the platform and the applications running on top of it.
For example: At Square you can take a payment on one device, in one application, then see it on another device, in yet another application. Then months later, refund it on yet another device, in yet another… and so on. All the while, sharing logic, security, compliance, and cost management that’s seamlessly kept up to date and managed on behalf of the seller and application developer.
Platforms can come in a variety of flavors.
External: It could be an external developer platform like the one I work on at Square, which is also used by our internal developers.
Internal: It could be a purely an internal platform like the content management system I worked on at Cox.
Hybrid: It could be a hybrid platform with a mix of purely internal product surfaces, and some external product surfaces. The tool I worked on at Kabbage was a good example, of this. It had an underlying set of APIs and SDKs which our external platform customers consumed to integrate into their CRM systems. But we also used it to build our own internal customer service tool.
Sharing in practice
To grasp the power that shared data, operations, and experiences that a platform enables, let’s look at a few examples running on the Square developer platform:
Square Virtual Terminal is a payment terminal that runs in your browser and lets sellers take over-the-phone and in-person credit card payments, either quick-one off payments, or itemized.
Bentobox helps quick and full service restaurants get beautiful web sites up and running quickly. From there they’ve got menus, online ordering for pickup, dine-in, and even delivery.
Simpletix helps event organizers promote, sell and manage tickets to in-person and online events, and manage ticket sales and will-call pickups at the door.
That’s three different products that all used a common platform to build their product. Let’s dig in and see how a platform could help them and their sellers:
Shared data. We focus on small, atomic units of data at Square, trying to break down objects into their smallest useful bits. Questions like “Should a Fee be its own API object, or an attribute of the Payment and Refund objects” are decidedly non-trivial questions for a platform product manager at Square.
These three applications could re-use these building blocks: Payments, Refunds, Orders, Items, and Locations to build their own unique experiences tailored to the business problem they were trying to solve, while gaining interoperability with any other application or experience running on the Square platform.
Experiences. That interoperability means that when you create a payment or a catalog item, it shows up in a host of seller experiences throughout Square that you don’t have to build. Whether you’re a developer inside of Square or outside of Square, the less you have to build to bring your product to market means higher team velocity, and faster time to market.
Value. A platform has to offer a value proposition to the developers that build on it. In addition to the time-to-market value prop, I spend my day focused on the managed payments value proposition — making everyone a payments expert by embedding Square’s expertise into the platform itself. Improving authorization rates, conversion rates, reducing fraud. Giving you a payments-team-as-a-service-in-an-API so to speak
Platform Customers
Let’s talk about why you and your team are valuable. Your customers and the problems you solve for them.
You are not a service team! You don’t take tickets in, and spit code out. You are a platform product manager, you fight for your customer. But wait, who is your customer?
At first blush this should be easy, right? Ask your analyst or engineering team to tell you who’s using your platform, and voila you have found your customer? Right? Right?!
It’s worth looking at who is economic buyer is. “Follow the money” so to speak. You, and the engineers working on your product get paid, I hope. Your business generates revenue somehow.
Does your product get direct revenue from applications that use it — say from usage fees, or subscription revenue? Or are the customers of the applications built atop the platform the ones whom are actually paying for your platform.
Let’s look at two examples…
First let’s look at Amazon Web Services. In their case, application developers are the economic customer of the platform. They pay for their usage of the platform – for all their EC2 instances, S3 buckets, containers, etc.
Contrast that with the Square Payments Platform.
In our case, the seller is our customer. Sellers pay for Square through payment processing fees, and have to be happy enough with the value we provide to pick Square — pick apps that chose Square, or pick Square when apps offer a choice of payment processing platforms.
In that light, platform PMs must view all the application developers out there as potential distribution partners who can help us get our platform product into the hands of sellers. We have to provide value to the developer, we have to market to them, all so they’ll consider choosing us to include in their application.
Double the research, you say?!
This is one of the hardest parts of being a platform PM. To be successful, you need to understand the struggles of your application developers, and their customers to ensure you’re prioritizing and building out what both groups need.
But you are not alone trying to do double the research. Chances are those application development teams have a PM or eng lead with customer stories and quotes, or anonymized usage metrics that they’d be happy to share if it helps them help you make the case for that feature they want prioritized this quarter. Enlist them as your allies, and your front line eyes and ears.
Avoid the trap of a lot of platform teams who become obsessed only with architecture, API designs, scaling, and performance. As a platform PM bring the voice of the developer and the customer into the conversation. Be the team that’s obsessed with the customer struggle… and architecture, API designs, scaling and performance
Platform Interfaces
APIs and SDKs
Most developer platforms offer two interfaces to their product:
Application Programming Interfaces, or APIs, are the core way of expressing those shared data objects and shared operations that we talked about earlier.
Software Development Kits or SDKs can come in two flavors – a native “wrapper” that provides a developer access to your API in their language of choice. Python, PHP, Java, etc. But more interesting to me are ones that provide those shared experiences across applications – likely with some customization. For example, Apple has SDKs to let developers summon a common “Share this” experience so developers don’t have to reinvent that particular wheel.
Side note: throughout this post, unless explicitly stated, I’ve been saying APIs as a catchall term for APIs and SDKs
Applications use APIs to interact with each other the way humans use GUIs, or voice interfaces (“press or say 1”), or text interfaces (ever use a command line?).
The bad news is that applications consuming an API can’t adapt to some changes in the API the way humans can adapt to changes in a GUI.
An A/B test of the fields or endpoints of an API running in production would be a disaster, for example. We’ll talk about what this means for how to validate your design in a moment.
Nouns and Verbs
The Apollo Guidance computer also ran on nouns and verbs.
I could do a whole course on API design. But at a super high level, imagine APIs allowing software to software interactions defined as Verb acting on a Noun.
The verbs are Create, Read, Update, Delete. Those are standard across the Internet.
The nouns are what are unique to your platform: Payment, Database, Contact, etc. For example: you don’t call the ProcessCreditCard function you Create (verb) a Payment (noun). You don’t call SetItemColor method you Update (verb) Item (noun) and include the color blue in the payload you send.
API Design and Validation
When it comes time to design an API, I highly recommend reading Mary Cagan’s The Four Big Risks. I want to focus on two in particular:
“Value risk – whether customers will buy it or users will choose to use it” and
“Usability risk – whether users can figure out how to use it”
These are both areas where in traditional products, visual designers add a ton of value. But the role of API designer tends to be an ad-hoc one played by someone different on each team — maybe the product manager, maybe the visual designer, maybe an engineer, tech lead, or an architect.
Whomever it is, I encourage teams undertaking API design to take conscious steps during their design work to focus on paying down these two risks.
The most powerful and cheapest tool in your arsenal is documentation driven development.
Once you have a sense of the customer use cases, sit down and write out the long form documentation. The “how to” guide that mixes narrative and API samples. Showing and telling how to use the API to complete the tasks that your potential customers value most — which you learned from your customer and developer research.
Share that with some prospective application developers — you can validate how easy it is to use, and if they’d choose your API over the competitions in an interview. Bonus points, you’ve validated that your API design meets your intended use cases from day 1, and the engineering team has nice narrative example of what we’re all trying to accomplish that they can rally around.
Dennis my general manager uses legos as a great analogy for good APIs and endpoints. They’re small and easy to understand. Your application can combine them into interesting and useful shapes, while another application can combine them into entirely different interesting and useful shapes.
Even if you don’t have a public API, chances are you have an internal one. Treat your internal APIs like your external ones. They deserve as much care and thought if you expect to get good return on investment out of your internal platform.
Put time and care into your API design, take the next 5 or 10 things you intend to add to your API after your first release and prove to yourself you can do so in a way that is backwards compatible. That is, you can add the feature to version 3, while developers on version 1 and 2 can keep operating without any issue. They might not be able take advantage of the new feature, but they won’t break.
Don’t be afraid of versioning – it’s OK to ask developers to upgrade to take advantage of new features. That said, know that a version upgrade can add to the already long timeline of application developers adopting your feature so consider those tradeoffs.
Be afraid of building the YAGNI API, endpoint, or field. You can’t walk it back very easily. (Image credit: Martin Fowler)
You should be afraid, well lets say thoughtful about releasing new APIs and new endpoints. If you haven’t proven to yourself that the case is there to invest not just in building it today, but in operating it long term, don’t build it.
If the team hasn’t satisfied itself that the interface won’t be obsolete in a few months and require breaking changes, keep working the design.
Once an API is in the wild, even and especially internal APIs, applications start using and depending on it and you’re left running it for a long time. The wrong design, the wrong abstraction, can and will absolutely hinder your ability to innovate and bring new platform features to market. That in turn makes it difficult for products to innovate on top of your platform. Worse, you’ll find yourself having to support the old poorly thought out solution, while also doing the big rewrite in parallel over a far longer period of time than if you had done a bit more design, research, and validation up front. Measure twice, cut once, because you will be operating it for what feels like a lifetime.
TLDR; Conclusion
Platforms build value through shared data and experiences, that’s also what makes them tough to build well
Two of the many things that set platform product management apart are how you approach Customers and Interfaces
If you don’t want to be a service team, identify your customers – even if they’re internal. Figure how who’s paying for your product, who you depend on to distribute your product.
Then research their struggles, and the struggles of the people using applications built atop your platform
Spend time on designing your APIs – they have long shelf lifes, you can’t walk them back like you can a visual interface.
Write the docs for APIs first against the use cases you’ve identified from your research as a way to validate the design, run it past potential customers to validate the value.
The latest excitement in our house has been the arrival of our countertop ice maker. Why are we excited about an ice maker? 🧊 Because it makes The Good Ice™ – those beautiful nuggets of ice that keep your drink cold, are great for chewing on, and make you feel like your out at a restaurant or tiki bar. I make a pretty decent mai tai, but this ice has taken it from good to great!
Saving my Mai Tai recipe here for posterity and sharing. If you’re not using the High Ball app, it’s a great way to store and share drink recipes.
Chris Heisel 