Building a high quality content ecosystem at scale
Fostering unexpected innovation by balancing flexibility and scale
The year was 1983, the video games industry was at peak froth and platform technical requirements were a process that, regrettably for Atari, had yet to be imagined.
It took just one release to tip an entire industry from ‘rocket ship’ to ‘rowboat’ trajectory — so what happened?
Quality.
The quality of a platform’s content is seen as the quality of the platform itself. Content quality is key for driving early adoption.
This is especially true for when you’re building out new platforms or expanding an existing offering to the mass market. Unfortunately for the video games industry of 1983, ET was a representation of just how much missed expectations can impact the success of a platform.
Happily for the millennial gamers amongst us, the industry not only recovered, it went on to thrive, with a 9th generation(!) of consoles launching to much fanfare in 2020. 🎉
OK, so, what kind of black magic was cooked up over the last 37 years that took us from the dumpster fire of ET to the cinematic marvels of Cyberpunk?
Achieving quality at scale
Frustratingly for us, in those 37 years no silver bullet was ever discovered. Fortunately though, the industry and it’s quality standards did not stand still, instead they evolved through a layered approach of trading off scale and flexibility as they went.
Introducing: ‘Grafton’s hierarchy of CEQI’. For the uninitiated that’s Content Ecosystem Quality and Innovation, pronounced “see-qwee”. Maslow, eat your heart out!
A natural first question to ask here is why flexibility matters. Why not simply technically restrict a platform forcing all content to meet a strict functionality criteria? Such a perfectly defined ultra scalable solution; an engineering delight!
Alas, to do this would be to eliminate all creative choices for your developers which would remove all opportunities for ‘unexpected innovation’.
Unexpected innovation is what a platform is at launch vs what the creative capabilities of your best developers can evolve it to be.
When Playstation 2 launched in March of 2000 it came with a well vetted input method; the DualShock controller.
However, due to technical and policy flexibility one developer was able to imagine: “hey that’s cool and all, but, what about if your controller was a GUITAR?!”. That one innovation led to a $2bn franchise. Not bad if you’re a platform holder that’s getting 30% of the profits!
Balancing flexibility and scale
Loving the idea of having a $2bn franchise on your platform? Me too! Ready to trash all restrictions and go all in on unadulterated, open ended, greenfield innovation? I say, easy does it old chap.
Balance.
Balancing tradeoffs is key to fostering unexpected innovation whilst simultaneously avoiding the abject chaos of unadulterated ‘shovelware’. Lets look at how we can accomplish this at each point in the CEQI pyramid.
Technical Restrictions
“What must be true for all content and can be represented with precision as part of your SDK/Runtime”?
These restrictions apply to all content and represent optimal scale, as by design, they require no manual intervention or verification. Usually manifesting as SDK APIs, they prevent some of the most egregious mistakes from happening.
Policy Restrictions
“What should be true for all content and can be represented by repeatable test cases?”
First introduced in 1983 by Nintendo via their Golden Seal of Approval, policy restrictions have been a key platform innovation that have ensured content quality at scale ever since.
Policy restrictions are usually represented via “developer guidelines” or “technical requirement checklists” and are often the sweet spot for trading off platform flexibility and scale.
Best Practices
“What’s the latest state of the art for quality on your platform?”
OK, so you’ve created a beautifully crafted set of platform APIs preventing developers from committing the worst atrocities and have a publishing gate that successfully upholds platform policies. Congratulations! You’re halfway there :).
Quality can be subjective. Based on this fact alone it’s impossible to capture all aspects as easily measured policies and concrete platform restrictions.
Best practices offer a platform holder the opportunity to “show rather than tell” via documentation, samples and case studies that can move you away from a “one size fits all” approach and towards a “here’s what could work well for your particular use case”.
Expert Assistance
“What is the most critical content that will the majority of users will experience?”
Pareto’s principle is alive and well when it comes to building out your content ecosystem. It’s no secret that the top 20% of your content will generate significantly more than 80% of your revenue.
In addition, at the early stages of a platform your technology is likely half finished and your developer partners are going to be excited yet thoroughly inexperienced, a dangerous combination.
Introducing the completely unscalable yet absolutely critical final element of the ‘hierarchy of CEQI’; expert support. These small yet mighty teams are composed of world class domain experts that act as the conduit between your latest and greatest platform best practices and your top partners.
Expert support is there to ensure your most critical content lands on time and at the pinnacle of what’s possible for your platform and that the platform continually improves as part of their efforts.
Evolving quality over time
Hol’ up a minute.
This grand unified theory of ‘CEQI’ is awesome and all but there’s just five of us right now, a half written SDK and a bunch of early access developers knocking down our doors, OMG WHAT DO WE DOOOOO!
Start at the top.
That’s right, start with the least scalable place and work your way down. Ya’ll who’ve been crunching over the last few years to build out this platform? Well, you right there currently represent the largest concentration of “Your Platform™” expertise in the entire world!
Step 1: normalize and document
See all those samples and tests you’ve written to ensure your platform functioned as intended? Well it’s time to start cleaning them up and documenting them. Now post them to a website. Congratulations, you’ve just created your very first best practices! Time to move on to step 2.
Step 2: identify systemic failures
You know when you were putting those samples together and you kept running into edge cases which required carefully crafted work arounds to ensure that it didn’t make your platform look TERRIBAD? Great! You’ve just identified your first policies that you’ll need to document and communicate to developers to ensure they don’t make your platform look awful either.
Step 3: encode policies into technical restrictions
There’s that one API, what does that one parameter do again? Damn, I always get this one wrong! Two things are happening here:
- Developers are wasting time on a platform nuance rather than making great content
- Developers are making preventable mistakes that may end up as quality issues for your users
Learn from this! Got two input API’s and know deep down that only one is usable? Do the right thing, take it out back and kill it off. Your developers will thank you for it.
Putting it all together
There’s one thing that’s a certainty in platform development; as soon as developers get their hands on it, quality and innovation will be a moving target and you’ll have to race to keep up whilst maintaining scale.
Key to accomplishing this is operating in a continual, cascading cycle:
- Support and learn from your developer ecosystem
- Translate these learnings into best practices
- Translate patterns in best practices into policies
- Translate systemic quality failures & gaps into technical restrictions (where possible)
Creating a platform that delivers quality content and innovation at scale is an ever evolving challenge. Pursuing a structured and deliberate approach to accomplishing it is a must if you want to build a platform and ecosystem that both your developers and users love.
It’s not an easy journey, yet, when you see that first third party content running and users delighting in the experience it’ll be more than worth it. Trust me.
Good luck, you got this!
