Designing Platforms for Evolving Work

Just over a decade ago, the emergence of Application Platform as a Service (aPaaS) technology changed the way users interact with their software tools. No longer were customization and application development the province of IT and software developers alone. With a little training, platforms enabled business users to design solutions to their unique problems. 

Since then, application development platforms have become easier to use, more sophisticated in their functionality, and transitioned gradually toward low and no code models, letting business users without significant–in some cases, any–technical training build enterprise-ready apps. 

That this is the case has been a feat of design and architectural genius. 

In his work at leading organizations, Adrian Kunzle has lead some of the biggest efforts in PaaS development. His teams have rolled-out some of the widest used platforms in the world.   

Recently, we were lucky to have Adrian Kunzle join us at Tulip for a day of workshops and conversation. At Tulip, we’ve built a Manufacturing Application Platform that lets engineers design solutions for their unique challenges and improvements. Naturally, we were eager to pick his brain about the finer points of platform development.

Kunzle shared with us his tips for creating a platform that works. For users. For developers. For enterprise accounts with thousands of users and mom and pop shops alike. 

Unsurprisingly, he spent a great deal of time describing how platform developers can build meaningful, productive relationships with a platform’s users. 

The conversation ranged from highly technical to eminently practical. I’ve tried to share a little of both here. 

These are the key takeaways from the conversation. 

1.) Q: How much of your platform is built around customer requests?

A: [Almost] all of it.

Much of the conversation with Kunzle concerned building around customer needs. The products Kunzle has delivered during his career are characterized by a singular focus on customer use-cases. 

He advised viewing these relationships as a partnership, one that goes beyond simply translating customer requests into product features. Rather, the best platforms work with customers over time to refine which features make it into production. The customer’s first request isn’t always going to be the best solution to their problem. The platform designer’s first solution isn’t always going to be the best fit for the customer’s. 

Through long-term partnership–having difficult conversations early and often–platform designers and users can arrive at a robustly functional, technically feasible solution. 

2.) Learn to spot “embedded philosophies” 

Organizations produce their own ways of thinking. Some arise in response to external rules and regulations. Others arise from strategy, market pressures, or tech stacks. Still others from company culture. 

Irrespective of where they come from, these “embedded philosophies” influence how companies make decisions and what they desire in new technology. Kunzle cited his encounters with “embedded on-prem” thinking, a mode of viewing where software is hosted influenced by the past limitations of in-house computing and data storage, as his teams advocated for a transition to the cloud. 

Despite the fact that cloud-based software freed organizations from the constraints of on-premise installations and updates, many organizations were so accustomed to the old way of thinking that they struggled to refine their feature requests for the new technological reality. 

Kunzle suggested that identifying these entrenched ways of thinking is key to a productive customer relationship.

3.) Beware rate of change

Not all users of a platform can handle the same rate of change. Some users might be ready to upgrade with each new release. Others might not be able to for reasons ranging from organization inertia to compliance to lack of due diligence. 

This means understanding how severely any update is likely to impact the core mass of users as well as being sensitive to the needs of those who might not be able to progress with rapid changes in functionality. 

At times, means putting effort into change management. At others, it’s gently (and sometimes gentle can still be rough) incentivizing users to make the necessary updates. At others it’s understanding that interia or regulations mean that some businesses simply won’t be able to keep up with change.

Success is figuring out how to encourage customers to move forward while understanding their particular aversions to change. 

4.) “Versioning is your friend”

This bit of wisdom came up in a discussion about API design, and how to best let end-users work with a platform’s API’s. 

A Tulip engineer asked what steps he could take to avoid letting APIs become “boat anchors,” to which Kunzle replied, “Don’t worry. They will become boat anchors.”

He noted that, in managing dozens of updates to an API, versioning can prevent many headaches. When versioning, you can keep slow moving customers on older iterations while moving the bulk through updates. Further, you can incentivize customers to update by only releasing features to new versions . 

He concluded this topic with a bit of weary humor, “Don’t worry. You don’t get your APIs right the first time. Sorry.” 

5.) Think in terms of personas

Different users will have different needs. This is a truism, but it impacts how platforms are designed. Kunzle recommended thinking about users in terms of personas, and fitting features to match how those personas will interact with the software. 

For example, an “admin” persona will need to set up the system, establish password policies, access controls, and manage users. They’ll have more complex needs than the end user, but not as complex as a “developer,” who might be building at a lower level and writing custom scripts. 

Building a successful platform requires understanding how these different personas will interact with the product in their work.

6.) Get a Minimum Viable Product into Customers’ Hands As Fast as Possible

The rationale here is that you can’t understand what a user truly needs until they’ve interacted with the platform and given feedback. By working at a breakneck pace to release an MVP, you can begin the dialogue with users early and keep it going.