Successful API Product Management in Large Enterprises
Ep. 9: Claire Barrett, Director at APIsFirst
Moesif’s Podcast Network: Providing actionable insights for API product managers and other API professionals.
Joining us is Claire Barrett, Director at APIsFirst and a seasoned consultant in strategy and technology change. In our podcast she identifies the key issues to ensure digital transformation success in larger, more mature organizations, and examines why digital savviness is key, how you should always aim for shared business goals, and why balanced teams are preferable.
Larry Ebringer, Moesif’s CMO, is your host today.
Listen to the episode on SoundCloud above or download it on Apple or Google.
Table of Contents
- 1:00IT-Enabled Polyglot
- 4:40Project to Product Mindset Differences
- 8:24Digital Transformation Takes Time
- 11:45Digital Savviness is Key
- 14:5360-40 Rule for Project Size
- 18:24Half your Resources are in Consultants
- 21:36Find Stakeholder Shared Goals
- 26:24Balanced Teams Perform Better
- 28:53Build Skills with Women in APIs
Larry Ebringer (Moesif): Welcome to episode nine from Moesif’s APIs over IPAs podcast network. I’m Larry Ebringer, your host today, and the Chief Marketing Officer of Moesif, the API Observability Platform.
Joining me is Claire Barrett, a seasoned consultant in strategy and technology change, with long tenures at international consulting companies and financial institutions, and currently the director of APIsFirst with Mehdi Mejowie. Claire’s also an active champion for women in technology and the leader of [Global Women In APIs]. Claire, welcome to our humble podcast network. Where in the world do we find you?
Claire Barrett (APIsFirst): Thank you Lawrence for inviting me. I’m joining you today from the UK.
Larry:: Great, I know it well.
IT-Enabled Polyglot
IT-enabled change polyglots speak the language of strategy, IT for business, business architecture, project management, scaled agile practices, digital transformation, organizational change and comms. And all of these come together in the API space.
Larry:: Kicking things off, why don’t you share with us your journey to become director at APIsFirst and the leader of Global Women in APIs, and perhaps illuminate on what were your drivers along the way.
Claire:: So my professional background has been in IT leadership and management consulting, almost always with, and around, large and more complex mature organizations going through change.
I grew up as a child in a military family, so I got to travel quite a lot. I changed schools, neighborhoods, countries during my, if you like, formative years, and it means that I’ve always been comfortable in new situations. I see it more as an adrenaline rush, than a fear. So I’ve always been drawn to helping people and organizations manage and thrive through change, and build the kind of skills, resilience and cultures that allow them to respond.
I’ve also got a real curiosity about the world. I describe myself as a sort of IT-enabled change polyglot, in that I speak the language of strategy, the language of IT for business, business architecture, project management, scaled agile practices, digital transformation, organizational change and comms. So to me, these all come together in the API space, and my role at APIsFirst was aligned with a move back to Europe from Australia, where I’ve been for most of my professional career.
We help people and organizations realize the full potential of APIs, generally as part of a wider organizational transformation. Joining APIsFirst also coincided with getting to work with the team around the API Days Conferences and their Global Women in APIs initiative. And I’ve had the privilege of leading that group, which is about building peoples’ confidence and skills with speaking and writing in public.
Project to Product Mindset Differences
Project Management is about chunking things down into small manageable pieces, iterating continuously, learning and moving towards a goal, whereas product management is ownership of the product lifecycle wrt customers, championing the vision for the product and finding new markets, channels and business opportunities for creating business value.
Larry:: Great. A very diverse background and again, thank you for joining us on our podcast network today. So let’s talk a little about product management in large organizations. How do you define product management in higher complexity mature organizations, and how is it different from project management?
Claire:: So an excellent question that a lot of people are wrestling with or thinking about deeply at the moment. Perhaps I’ll start with how I define project management, or what is it about, its essence.
Project management are about three key things. It’s about achieving a particular sponsor’s vision and goal, and project managers typically have quite a close emotional connection with the sponsor’s dream and vision. It’s secondly about ownership of deliverables and about running processes to execute that change across technology, people and skill sets. Good project managers can own deliverables and run the process to execute, often regardless of which industry or underpinning technologies or types of teams and problems they’re solving. Good project leaders and the more experienced they are, and the wider the scope of the change that they’re used to driving, the more able they are to be dropped in to solve complex problems, regardless of what the project’s trying to achieve. And the third thing is really about how they organize and do their work: planning the work and working the plan is a typical mantra. These days, this is about chunking work down into small manageable pieces, iterating continuously, learning and moving towards a goal. So those are some of the themes around project management.
Product management would have a different set of things that are important that they would rank. Since they have ownership of the product lifecycle, they’re looking much longer term than necessarily getting to the end of a project and a scope. They’re championing the vision for the product in the API sense. It’s about finding new markets, new channels, new business opportunities for creating business value. Secondly, they’re very customer centric. Now those customers in an API sense could be other developers in other organizations who may be looking to create models, or they could be focused on products that are being digitized and automated through APIs. There, the emotional connection of a product manager is more strongly to its customers, to the users of the product. For APIs, this is the potential that other systems will use it to fire up those teams. And the third thing that is important for product management is a very data fact-based evidence element to the decisions that they’re making.
The project manager and the product manager both share strong commercial acumen, they need to be able to manage and drive change, they need to be able to move things forward and drive action, they need to influence and communicate across very large and diverse groups of stakeholders. They both have roles in bringing people together, who may not necessarily work for them directly, so they’ve got to be able to operate through influence.
But I do think they have a different emphasis and connection. I don’t think you can just rebadge a role that looks under the covers a bit like a project manager, because they’re just good at organizing things and getting stuff done, and re-label it as a product manager. I think you need to be thinking of product managers as deeply connected to understanding the business subject — they’re deep business subject matter experts in the capability of what’s being offered, and their level of understanding in an API sense can’t be necessarily agnostic about technology in the same sense that perhaps project managers are able to operate across more domains.
Digital Transformation Takes Time
Especially in larger, more mature organizations, modernizing existing systems is about building skills and confidence with trying things out, learning from them and then moving ahead — analogous to leveling-up each step in a game
Larry:: I think you hit the nail on the head. I always love to slow down in these podcasts when there’s an especially cogent moment, analysis or insight. How does product thinking manage the challenge of meeting short term priorities, whilst transforming more broadly? Or, put another way, how do you re-engineer a whole plane while it’s flying?
Claire:: So I think striking these balances is such a real problem for people, particularly in larger, mature organizations that are striving to simplify, automate and modernize their existing systems, at the same time as trying to find new opportunities which potentially, if not well managed, are at risk of adding complexity into the environment. So how do they do the “walk and chew gum” thing?
The organizations that are getting the most success in this space are able to right-size the levels, their architects are able to focus on particular domains or particular areas of business and technology, and have the right organizational structure and ownership for it. But it’s also a lot about how they fund and manage the ability to prioritize. So, as one moves from project-based change to more product-based thinking, going along with that is the ability to think of long build and run capability as being long running through the life cycle of a product, as distinct from being time-bound and scope-bound in a traditional project tense. And this certainly plays out in things like what’s OpEx versus CapEx, it plays out in things about what’s business as usual versus what’s change. So, it can go quite heavily to the core of how organizations have traditionally thought of change. In order to be able to respond. But they can do experiments and build capability if you’ve got the right kind of attitude and they can chunk things down to be small enough, rather than try and overthink it too quickly.
It’s a lot about building skills and confidence with trying things out and learning from them and then moving ahead, it’s like leveling-up each step in a game. As you’ve leveled-up into the teens and the 20s levels, you can deal with an awful lot more complexity and stuff coming at you all the time from different places. And the prize is bigger and you can collaborate with different people than you thought of in the past. Early on you need to build skills and muscles at managing change.
Digital Savviness is Key
Offering external APIs into new markets often feels very different for people and so digital savviness for the sponsoring teams and product ownership is key to successful product development
Larry:: Great. Love that definition. It’s a lot about moving slowly initially and then building upon the, as you said, muscles and the skills that you’ve built up over time to really formulate large-scale change. What cultural, behavioral levers need to be pulled and where should you invest to make a product successful across large organizations?
Claire:: So if we focus in on API products in particular, they do call for a different way of thinking than APIs as integration components. A lot of people can quickly understand that it’s not a big stretch in thinking of APIs as a better and simpler way of providing hooks between systems and hooks between external parties and organizations.
What’s a next step of thinking is how might an API externalized be offered as a product into new channels that don’t yet exist and into new markets, as opposed to re-engineering, or offering a new experience, this is offering a product in a new sense to a new market which feels very different for people. And so a digital savviness is for the sponsoring teams and product ownership is key. Having the right fit-for-purpose governance in place that underpins and supports those API products and teams around them. So the very clear and easy to understand minimum standards and expectations around security, around usability, around data management.
The other, as we were talking about before, this project to product mindset, as well as being understood by multiple different stakeholders in the organization is key. So it is about building that capability, finding the places that early on will resonate and that will tell a story that can be bought into by people.
So what is the particular opportunity, which early on might not be as far reaching as once you’ve leveled up a number of times, then you can kind of be exploring more progressive ways of working. But, by then you’ve sort of built a momentum and you’ve got the engineering confidence, you’ve got the scalability confidence, the performance confidence, the security, the finance, funding arrangements, those capabilities that need to be in place.
60-40 Rule for Project Size
In digital transformation it’s been identified that at 60% of the effort in higher-complexity organizations goes into projects that have a big long-term impact versus 40% into low-hanging fruit pieces of change, whereas in lower-complexity organizations that split is the other way around
Larry:: Yes, I totally see that in our customer base. What do you mean by when you say achieving change stickiness and what are some of the things people can take away from your research findings into it? And I should probably say that I got the idea for this question from your excellent LinkedIn article on this topic.
Claire:: Thank you Lawrence. Transformation change stickiness has been an interest of mine in terms of what IT-enabled change leaders, so these are tech-savvy business leaders, CTOs, CIOs, consultants supporting organizations through transformational change and seasoned technologists, what are some of the trade offs they are encouraging or making that allow them to do this building and repairing the plane while flying it at the same time? And the findings have been interesting and they are actually different depending on the complexity and size of the organization.
So, there’s an appreciation that if you’re driving large change and you’re looking at it through an IT-enabled change lens, there are ways in which you can be more or less effective, depending on where you want to put your efforts, because there’s always more things that you can do than you have enough resources, teams, skills, funding, to go after. So how do you choose what to do, how do you choose what to do later, or what to not do?
At higher complexity organizations, for example, they would put 60% of their effort in getting attention for the change that’s going on, they put 60% of their effort towards large symbols of new things that are being done. Versus 40% of their effort towards what I call the kind of low hanging fruit pieces of change, so the things that will show that there’s some change happening but they may not be the really, really big long term impact. Whereas in lower complexity organizations that split would be the other way around — it’s actually more like they would put 65% of their effort towards things that make a meaningful difference, low hanging fruit or problems that have been around for a while, that by addressing them, they will get trust and confidence from employees and customers close to the coalface of their operation and then support some of the bigger symbols of change.
So big symbol of change could be a major reorganization around perhaps a different kind of scaled agile arrangement. It could be a change in language, I’ve heard of changing an international language for a non-English speaking organization into English, for example. So something that’s kind of gets people sitting up and listening.
Half your Resources are in Consultants
Given the war for talent in APIs, almost 50% of companies’ talent in digital transformation comes from external consultants
Claire:: Another piece that I ask people about, which I think is very relevant in the API space, where there’s a big, if you like, war for talent at the moment in terms of finding for example API product managers, is where people would put their efforts and investment in building skills and capability in house, taking perhaps a bit longer to recruit and to retain and build new capability that will will drive their transformation, versus what effort would they put into getting externals into help them with a with a fast start. And, regardless of the size of organization or industry, it was more than 50%, about 55%, of their efforts would go to building capability internally, versus nearly half, 45%, on external support. So again, both options are reasonable things to choose, but there was a recognition both by external consultants on the importance of organizations building internal capability, as much as they was the recognition for people trying to build skills in house, about the need to be able to get support from externals.
Larry:: That’s fascinating. I would have never thought that it’s 50/50 for building internal capabilities, versus bringing it in from outside.
Claire:: Yes, just to qualify, it’s 55% of the effort that they would put towards building internal capability, versus they would put 45% of their effort towards getting help from outside, in driving a digital change. So people recognize that they need that long term capability in house, it’s just they don’t necessarily have the time, they can’t afford at the moment to take the amount of time, it will take to build that capability in house, either re-skill existing people with new digital capabilities, or with finding and recruiting those people, they need the external support to give them that head start. With a net strong expectation that that role is to coach and support the development of that capability, as opposed to having a long term third-party reliance, on something as core and fundamental as the API space. For example, if you’ve got API products that are building out an embedded business model for you and you see that as part of your future, and the people that are supporting that as having the capabilities that you want for the long term, then you don’t see that as something that you need to outsource.
Find Stakeholder Shared Goals
To ensure lasting change identify shared goals between the different API stakeholders: sponsors, transformers and technologists
Larry:: Right. In fact that’s very topical. We have a number of new customers in HealthTech and it’s fascinating that the earlier on the customer is, the more likely they are to have external consultants helping them with HIPAA and HITECH compliance. But then when dealing with larger organizations in HealthTech, that have an established product and are further down the path, practically all of their expertise is internally built and developed. So we certainly see that in our market today. How does your proposed model of API stakeholders work where sponsors, transformers and technologists interact to execute lasting change?
Claire:: So the description that we use is that these three different communities, if you like, within a lot of organizations today going through transformational change, is not an organizational hierarchical split. It’s more of a role between these kind of elders, the sponsors of the organization that are looking to realize the strategies that they’ve committed to and want to see realized as quickly as they can. Inevitably while APIs may not be called out in those strategies, they certainly are inherent in the ability to be able to move faster, be able to explore and participate in new ecosystems and new kinds of models and marketplaces. So that’s the elders. The transformers or the explorers are the people who are out there looking for new opportunities. They may already be at a kind of API as product base, or they may be focused on perhaps digitizing existing experiences or re-imagining customer journeys. Then the third are the technologists, the kind of navigators of the IT landscape and the tooling and the architectures and the enablers, of which APIs are certainly a core.
One of the challenges for these groups is not to have them standing with their backs to each other, trying to shout into the wind, but singing from a shared song sheet and finding the synergies in the white space between the teams. They do often have different starting points, all correctly and appropriately intentioned towards driving this broader change, but are not necessarily aligned around the same priorities. So all focused on the things that are closest to where their function will make the highest impact on the organization more broadly. But that can create tension between which things to work on first. So finding the shared API goals is really critical. At the lower levels this may be relatively small, in terms of its ambition and scoping opportunity, but as organizations level up it may be across all three.
So early on, maybe just two of those teams would be working and focusing on something such as the APIs that are going to enable processes to be digitized faster. The IT team working on the tooling for that, making sure that those can be secure and self-served internally. That may lead on to some other impacts more broadly for other sponsors. But then the transformers may be looking to actually trigger more change in the elders, the sponsors community, to start thinking differently. The IT teams may actually be able to offer new ways of thinking about that, that hadn’t existed before. And creating the right constructs for those three parties to operate together could be around a product, or it could be around a program in order to inform the product, is for me part of the secret sauce for getting fast impact at each level.
Balanced Teams Perform Better
Teams that are more balanced when it comes to gender, race, culture, age, orientation and ability, are more creative and successful than homogeneous teams
Larry:: Fascinating distinction between those three different, very important, groups. So changing gears a little and moving on to a topic close to my heart, since I have two daughters. Share with us your experiences of being a leader of women in the API community. What are the benefits of greater workplace balance and inclusion for product teams?
Claire:: So product teams are naturally expected to be creative, to be responsive, to be thinking not just about technical product opportunities, but empathy and the feelings and sentiments of their communities and user bases. And so greater balance in a team will naturally create a more diverse way of looking at problems. And you know balance is not just gender, it’s race and culture and age and orientation and ability. All of those elements will allow people to think up products that are more creative and that are more responsive.
Another key thing is that people are more engaged if they feel included and will bring their whole selves to work and be more connected. So inclusion pays up very heavily in increasing staff engagement. Personally I think that diverse teams are more resilient to change because people are more open to others and to others’ ideas, and therefore they tend to be more sensitive to what’s going on in the external environment. Certainly, research bears out that organizations with greater balance in their leadership teams and greater balance in their board of directors, will respond more successfully to change. That couldn’t be more real than what’s happening in the world today.
Build Skills with Women in APIs
The programs run by Global Women in APIs initiative helps people build confidence through enhancing skills in public speaking and writing
Larry:: Right, that is so true and so cogently put, especially here in Silicon Valley where you need a whole lot more inclusion and diversity in the tech workspace. So on that subject, as the leader of Women in the API community, what do you suggest that under representative people listening to this podcast can do to help further their careers, and specifically what programs might be available.
Claire:: We run programs to help people build their confidence and skills with speaking and writing in the public domain. So we feel strongly that people who can showcase the talents of their teams, their colleagues and by association themselves are building the opportunity to be recognized not just externally, but internally as well. And we feel that as people build confidence with speaking about what they and their teams are doing, and how that’s making a difference, that that encourages perhaps less represented other team members to step up to contribute.
We support people in their careers by running programs that allow them to practice in a safe space. Applying to speak at conferences, for example, we provide them with coaching and support before, during and after conference participation, and increasingly now in writing in the public domain. We provide networking events and we support profiles of women in the APIs community, which is, I should say, pretty broad. Last year we increased our membership by 150%. We offered five programs. Our Members are now from over 23 countries and more than 85 different organizations and the membership’s growing literally by the day.
The Members come from large organizations with API architecture roles, they come from API management system vendors, they come from startups, they come from freelancers in the API space, technical writers, UX. It’s a really fantastically broad group with men, women and people identifying as non binary, in our membership. It’s been a fantastic way, particularly for people who are perhaps a little less connected in this pandemic world that we’re in, to provide connection through a virtual format. For people in all corners of the world this has provided a really important feeling of being part of something that’s bigger than one is.
Larry:: Brilliant. Where online should people go to find out more information about your excellent programs?
Claire:: So women in APIs is at the initiatives page of APIDays. You can join there and find out about the programs. You can contact me on LinkedIn,{:target=”_blank” rel=”noopener”} if you want to contact me directly. On the subject of API Product Management, as part of a group of global API experts at the API Collective, we’re running a API bootcamp program from the 23rd of March, with more details on the API Collective’s training page.
Larry:: Excellent. Well, we finished on a very instructive and helpful note providing a couple of great links for furthering one’s career. Thank you very much Claire for taking time today to cover such interesting and important topics. We wish you the best and stay safe.
Claire:: Thank you Lawrence. It has been an absolute delight to have you here and I look forward to following the continued success of Moesif.
Larry:: Great.Thank you very much.
Claire:: Thanks
Make Your API Platform Successful With Moesif
14 day free trial. No credit card required.
Learn More
Related Articles
API Analytics and Monitoring
Introducing AI Explain
We are thrilled to introduce our newest feature to Moesif - AI Explain - a powerful conversational tool that lets you interact with your API analytics data l...
API Analytics and Monitoring
Monitoring Cost and Consumption of AI APIs and Apps
Discover how Moesif can help manage and optimize your AI-driven APIs with powerful observability tools that track costs and usage efficiently.
API Development
Unlock Deep API Insights with Moesif’s HTTP Body Analytics
Learn how to use Moesif to analyze HTTP bodies.
API Analytics and Monitoring
How Moesif API Observability Compares to Treblle
Learn how Moesif’s API observability platform compares to Treblle.