De-risking Product Development with the Product API

Over the last few years, enterprises have been forced to digitally transform, quickly. Customers of almost every organization expect to conduct business online, seamlessly, and in ways they find pleasing. If those demands aren’t met, users will seek alternative providers who will.

As companies approach us to help meet those user demands, 3Pillar Global has recognized repeated patterns of client needs. To meet those needs, while minimizing time to value, we’ve developed the Product API layer. The introduction of a Product API layer lowers the risks of creating new products, and is the key to delivering great products on time.

The purpose of the Product API is to ensure that the APIs that support the end-user’s experience meet the high demands of a quality product experience that they’ve come to expect. Enterprises are particularly challenged in providing great digital products because a significant amount of their existing API inventory is intended to serve internal users and use cases, and are insufficient to meet the demands of a single digital product or multiple product experiences.

We notice the deficiencies most often when our clients tell us “we already have great APIs”. And in all fairness, they do. They have great data APIs, but what they don’t realize is that their data APIs can’t be effectively consumed for front-end development. And that’s where the Product API comes in.

Be agile, run fast

At 3Pillar, we use a “be agile, run fast” mentality. We are outcome focused and not code focused. Agile software development is based on the rapid development, testing, and deployment of code in small iterations designed to accomplish specific goals that make our customers’ lives better. It’s this methodology that enables us to bring new features and functionality to our platform in a timely manner while still keeping high standards for quality control.

Agile software development requires close collaboration between members of cross-functional teams (like developers and designers) from different departments (engineering, product design, etc.) using tools that allow for frequent iteration over tasks. Our multi-track agile approach allows a decoupling of the front-end developer’s work, from the back-end team’s deliverables. But we developed the Product API because we recognized that this multi-track agile approach was lacking the tools that would decouple front-end from back-end and had higher risk if front-end and back-end development had different workstream or asymmetric backlogs

Decoupled workstreams leads to multi-track agile

The major benefit of decoupling is that you can split the work across multiple teams and work in parallel. By defining the Product API interface up front, we are able to start our UI work before the backend deliverables are completed. This means we run usability tests early and fix issues as they come up, rather than at the end of development.

We also run design and front end development on different, parallel tracks. Our design team uses its own agile track that feeds the front end track. They design the overall user experience—defining what the experience will be. They define the data needs for the experience, not simply for the screen design. The Product API might need to access a number of systems to get what it needs, but it’s agnostic as to exactly what, and where, the data is. It allows us to devise best-in-class interfaces quickly, without having to wait for code. Another benefit is more flexibility in the frontend technologies we use. Working at scale means you want to be able to pick and choose the best tools for your job, but using a monolithic backend system can limit your choice.

Decoupling also gives you more control over your own destiny, which can be crucial for large companies with multiple teams working together on one product or when integrating with third-party systems that may not always play nice with your codebase or development process.

Tighten feedback loops between research and development teams

User research is often treated as a separate entity, but at 3Pillar it’s an interdisciplinary function. Our researchers help product managers be more accurate with their specifications and get better products out the door. The Product API also allows the researchers to conduct tests with iterations that more closely resemble production versions of the product. After all, developers are going to have to implement these ideas anyway. If we can bring all the disciplines—user research, product, and developers— into the conversation early, we can build an experience that’s more likely to work in practice, instead of just on paper.

Conclusion

One of the principles of our Product Mindset is to minimize time to value. The Product API provides the ability to decouple the freedom of designing a best in class user experience from a looming specter of potential technical limitations. The Product API creates a scalable scaffolding to build meaningful experiences at speed, while ensuring the ability for those experiences to deliver their value proposition.