The Platform Story: Part 3
Previously on…
In Part 1: Orientation, and the problem statement, we started to get oriented. You could say it delivered on, but did not exceed, expectations.
In Part 2: Background and Goals, we talked about goals, and I briefly introduced myself.
See? Titles are an important part of expectations. Ok. Onward!
Things you should expect to do
Take the plunge
Let’s get this out of the way: spinning up a platform offering isn’t really something you can half-ass successfully. You can do it slowly and intentionally. You can learn and pivot as you go. In fact, you’ll need to learn and pivot at least a couple times. You can also keep your team relatively lean as you test the waters of whatever market you’re in.
But you have to commit.
This will be obvious as soon as you dive in, but it’s important to mentally prepare yourself (easy), and your organization (less easy). When you’re building product, every new feature creates new maintainable, expandable surface area. The same is true for platform, but with the added twist that you won’t be able to predict what other people do with the tools you give them.
If things go well, you’ll quickly end up with more surface area than you know what to do with; and while that’s technically a good problem to have, it can get overwhelming — especially if you get yourselves used to that sweet, sweet, untethered “startup within a startup” development pace.
Stay flexible
It’s all well and good to have deep plans and roadmaps and justifications for all the neat things you want to release into the world. Those docs will help build consensus, as well as give your organization and customers some proverbial tires to kick, and that’s great.
But because you can’t really predict what parts of your toolchain will garner usage, you have to stay nimble — and that cuts in both directions. Some of your experimental features might suddenly pick up overnight, and some of your sure bets will die on the vine. And that’s ok. Adoption is adoption. But you don’t want to end up overcommitting your strategy, so it’s good to practice honest reflection.
Ask “why?”
You’re going to do this a lot. Why prioritize this feature over that one? Why spend your time focusing on this partner, and not that one? Why write a guide, or help a specific customer, or build a deck, or spend a week focusing entirely on internal education?
Honestly, some of this is going to look like best guesses and winging it — but do what you can to build metrics around your decisions (more on this coming in Part 4). This will help you when you need to answer a tough “why,” and also when you need allies — which will be often.
Build consensus
Docs will rarely be enough — and that’s where crossing department lines is your best move. For example:
- If your org uses Salesforce, then get your partners in there quickly and get them associated with your deal pipeline so you can point to dollars if you need to make a tough priority call.
- If you have a customer support funnel, find a way to get your inbound requests into it — the more people in your org are exposed to the types of Q+A that accompany your work, the better.
- If you have instrumentation for product metrics (Looker, Datadog, GA, etc), get your platform metrics tied in there.
You’re not only helping yourself build up shareable methods for making good decisions — you’re socializing your work, and enabling your organization to join you on your journey.
And if not?
Let’s assume the plunge has been taken. Everyone’s agreed to give platform development a fair shot, you have >zero resources, and at least a 3–6 month runway to try stuff. Now what?
Flexibility, reflection, and consensus create a mutually reinforcing structure. Speaking from frustrating, recent, and largely self-inflicted experience: take out any one side, and the other two collapse.
Inflexibility
You’ve stopped pivoting. You’re missing market signals in favor of charging forward with a roadmap. Suddenly, other priorities that have been more thoroughly vetted creep ahead. What happened? “Things aren’t getting done,” and you’re “going off plan!” It feels like a fire drill, but it’s just change. Embrace the pivots — otherwise, someone else will, and you’ll end up losing whatever consensus you had.
Overconfidence
If you stop asking “why,” you stop having considered answers, and all that can fill the gap is raw-ass confidence. That’ll keep you afloat for about as long as your personality allows, or until you start losing concensus — whichever comes first. Overconfidence will also tend to ossify your planning — no point I in changing an untested-but-definitely-correct hypothesis, right?
Lack of consensus
Ah. Yeah. So this should go more or less without saying, but if you don’t have people supporting your goals, and advocating for them when you’re not in the room, you’ll end up tired, battered, and alone. You also might feel an instinct to get loud and double down, which will wind up with you seeming — and being — less flexible.
Setting expectations for others
Right, right. The other side of the expectations coin.
This is a tough one, as setting expectations outside of your immediate working group has a combination of interrelated and potentially squirrelly factors. For example, internal stakeholders, company mandates, preexisting strategies, market expectations, and partner needs may all collide. And because all those entities are autonomous, all of them are subject to mutually uncoordinated change.
Some of this is a classic product prioritization problem, some of it can be solved by setting framework-driven goals, and some of it just plain sucks.
Really, the best thing you can do here is make a list of each external expectation, attempt to align them with your goals, figure out what you can and can’t ignore, and do your best. Above all else, communicate twice as much as you think you need to.
Yeah, but
If I’m being honest, I didn’t do this while we were getting off the ground. If I’m being extra honest, I still haven’t done this; and most companies I work with are pretty obviously also not doing this.
Hot take: everyone sucks at stakeholder management — at least a little bit.
Sometimes sneaky is good
Also worth calling out: depending on your situation, you may be able to squeeze extra bandwidth and runway by flying under the radar a bit. I’m personally a big fan of this move, as it reduces the pressure on early experiments, and talking about what you’ve already done always carries a bit more weight than talking about what you’re going to do.
In Frame.io’s case, the early days of platform sat just far enough outside of a busy product/design organization, and we got just lucky enough with marketing timing that we were able to operate with almost unlimited leash for nearly a full quarter.
But that won’t work in all cases, and even if it does, you might experience unintended consequences; so don’t say I didn’t warn you.
Previously:
Coming up:
(By the way, this list is entirely subject to change).
- Part 4: Risk and measurement.
- Part 5: Choices, mistakes, and lessons.
- Part 6: More choices, more lessons.
- Part 7: The partner pivot.
- Part 8: Keep your head in the game.
- Part 9: TBD…
