Under the ARC with Nonso Maduka, Product Lead at Plaid

In the third issue of Under the Arc, our co-founder and Managing Director, Daniel Eisen, sits down with Nonso Maduka, currently a Product Leader at Plaid, a leading Bay-Area Fintech. In this issue Nonso talks to us about the core measures of success for a Product leader, how they engage with other functional leaders within a software business and the tools required for success in the role. Read more below…

As a starting point, can you give us your background starting from leaving school and through the couple of stops in your career up to where you’re currently at today with Plaid  

I currently live out in the Bay Area, but I was originally born in Nigeria. My family immigrated over when I was young, so you mostly hear the American accent, but the Nigerian roots still run deep. I went to Princeton, and studied electrical engineering, but I was one of those weird kids that from a young age knew I wanted to be an engineer. My mom was a chemical engineer so I was surrounded, and I was always attracted to the idea of translating theory into reality. I wanted to build the thing rather than just talk about building the thing. I think that journey of testing, iterating, building, and creating things was just fascinating to me. 

Coming into college, I thought I was going to go start my career as an engineer for Bell Labs or NASA. Instead, I ended up in the finance world as a mortgage trader at Citi. Ironically, most of the folks I worked directly with were also electrical engineers or from other technical backgrounds, so I found like-minded people to engage with. I started at the onset of the 2008 financial crisis, and you can imagine what a ride that was like as a first job. I learned a lot through those first couple of years. 

While I was at Citi I started angel investing with a few fellow associates and other colleagues, which sparked my move from finance into the tech industry. Watching the businesses I was invested in building and capitalizing on opportunities out in the market, drove me to want to be part of that company building journey.  

From Citi, I went to Harvard Business School ahead of transitioning from finance into the tech industry. I joined NerdWallet, a company focused on helping consumers with personal finance decisions, and led product initiatives for a few of our verticals, including student loans, auto loans, and small business loans. From there I joined Glassdoor to lead product teams and solve some important problems related to helping folks find jobs and build great careers. 

I’m now at Plaid in a product leadership role, where I focus on leading product teams for our core data aggregation products. We provide data connectivity solutions to help empower builders in the digital finance space. Our customers are building the next generation of the financial ecosystem, and we work to enable their development of new financial experiences for their users. 

For those that might not be as familiar with the dedicated PM function, how do you measure success in your role as a product leader?   

Above all else, topline success is about delivering outcomes for customers. In Product Management you don’t write code, develop designs, or directly sell, but you can drive impact by making high quality decisions about what is the best thing to build for the customer. To measure the success of a PM, we think a lot about decision making quality over time. We might measure this based on revenue, customer adoption, retention or other fundamental metrics of a business. 

From an internal point of view, we keep a close eye on the pace at which we are able to get things done. While decision making quality is important, we don’t want to take forever to make those decisions because we learn best by putting solutions in front of our customers and getting their direct feedback. We look at metrics such as development velocity, shipping cadence, and more to get a feel for how quickly we can get things from ideas to solutions.  

Can you describe how a product team interacts with other functions in a company? For example, walk us through how you work alongside Engineering and the Sales/Marketing teams.  

Product managers typically don’t have formal leadership power from a cross-functional standpoint. Instead, our team interacts with many other functions as peers, and we drive action through influence rather than explicit command. The role is fun because of this interaction, fluidity, and team dynamic. One day you could be focused on sales and marketing, and the next day on support or engineering.  

With Sales and Marketing, the focus is on how effective we are at distributing our products to new and existing customers and getting feedback to improve existing products or develop new solutions. We want this to be a two-way street where we’re learning from each other to support our customers in the best way possible. With Engineering, who we tend to work the most closely with, we’re talking about how we discover and deliver a great product. We are trying to solve complex problems and decide how we translate what we’re hearing from customers or observing in the market into a product that will have a lot of traction with customers. This takes the form of planning sessions, daily huddles, and testing to deploy something that delivers great customer outcomes. 

Lastly with support, which is overlooked in some companies but is critically important, this is where we find out how the product is being used to ensure its being adopted as successfully as we’d imagine. At times the way a customer uses a product may not be as exactly as intended based on design.  

The nature of the role is wearing lots of different hats and engaging throughout the organization. 

Do you think product should exist in a separate team from engineering?  

It’s important that the product is an independent function, because having a seat at the table that’s dedicated to the product is critical, especially for major decisions. It ensures that no one function is overly dominant, and the customer remains the top focus.  

In early-stage companies much like the ones Arcadea spends time with, the founder is likely the champion and voice of the product and creates that executive focus on the product. As the company scales though, it will typically need a dedicated executive leader who can be that voice within leadership. There is a natural tension that exists with product, engineering, design, and going to market teams, which I believe can help lead to better outcomes for customers. Maintaining functional independence helps to foster this.  

We know you have experience as an Angel investor with small software businesses who are in the early days of building organizations. All the businesses we engage with at Arcadea have reached ‘escape velocity’ from their start-up days but may not have established a product team or role. Tell us, how would you structure a product team in a small business?  

One major mistake is building too big of a product team too early. The product function can often be the CEO or the founders for the first several years of a company.  When starting to think about building a product team, a business owner should first think about what gap they are trying to fill by adding a product manager – is it about product execution? product strategy? a combination of both. If you do see a need, then it’s important that there is an environment that is empowering for product. They should have relative autonomy to decide how to translate longer term strategy and business goals into what needs to be built for customers. Giving a product leader the space to do so is critical to their success. At 30-40 FTE you don’t require a scaled PM team. Products should be impactful, and one or two Product Managers can carry the business for a while. 

Shifting over to your experience at Plaid – It’s an amazing organization, having achieved massive scale in a short period of time by executing on big, industry-changing ideas. How do you balance the idea of dreaming big while also staying focused on achieving measurable incremental progress in the short-term?  

This is the existential challenge. There is always a strong desire to take big swings, but there are day to day steps that need to be taken to reach that larger outcome. We often talk about the idea of having a vision and north star goals that can help inspire the teams and guide us along the path ahead. As we make day to day decisions, or debate whether the next step is the right step, we can point to that longer term vision as a guidepost for the immediate decision ahead of us. I think about the idea of painting the vision, then working backwards from that vision to where we are today, and then executing day in and day out against that map we’ve built. 

Back to my earlier comments about Engineering and turning ideas into reality, it’s the same challenge here. The faster you can take steps of turning ideas into reality is how you can right-size the balance of dreaming and making incremental steps in the right direction. It’s rarely one swing that delivers the impact you’re looking for, but rather a combination of the seemingly small activities.  

How does this happen tactically today?  

Typically, we work from a high-level hypothesis that guides the set of objectives for the team. We’ll translate these objectives into large blocks of work that we want to work towards. For example, an objective might be to “raise customer adoption”. We’d break down that objective into individual pillars by asking ourselves lots of questions. For instance, we might ask, “how is onboarding performing for our customers?” and trying to understand whether we can make it better to improve customer adoption.  We’d then break that down further into component parts, such as looking closely at individual onboarding steps or understanding holistically if the sign-up flow is too dense.  

What tools do you employ in your day to day?  

We use a whole range of tools, and it’s been really cool to see the proliferation of productivity tools over the past few years. Some examples are Jira for planning and orchestration, Google suite for documentation and collaboration. For testing and experimentation, we’ll use tools like Optimizely where we can test and measure impact on segments of the audience. We’ve also built a few home-grown items on our own to manage specific workflows as well. 

Plaid is well known for its API-lead approach to serving the market. What does it mean for a company to open an API up to the world? Can you give us your take on when it makes sense to use an API first approach as compared to a walled garden?  

There are a few things to consider here.  

First, a decision like this needs to be heavily tied to your company’s overall strategy and competitive strengths. What’s your motivation for taking an API lead approach? Is this about delivering a better customer experience? Opening a new distribution channel or source of revenue? Will customers benefit from the service you offer in a meaningful way? 

Next, you need to consider whether you have the technical readiness to expose an API out to the ecosystem. At Plaid, we know we have a large responsibility, since we know that our customers are building their businesses on top of the APIs we provide. Their success is determined by our success, so reliability, quality, and security are all critical for us to get right. For folks pursuing this path, they must ask if they are technically ready to deliver APIs, and services to support customers and their business success. APIs must be viewed as a product and service line on their own, it is a product in and of itself, not just the opening to other technologies. It requires the right amount of investment in resources to deliver this to the market and if those resources are not available, it’s best not to pursue. 

Are there any metrics that business leaders can think about when deciding whether they should pursue the API approach?  

I’d encourage leaders to think about the value of releasing this data to the world. Take Twitter for example. One goal they have is user growth and increasing the number of active users on the platform. There are a range of activities they can take and have taken to help drive this metric, but a public API can be part of this toolkit. Their API can open a distribution channel for them to reach even more potential users by enabling websites, publishers, and other platforms to embed tweets directly into their experience. This becomes a pathway for more folks to engage with and discover Twitter.  

On the other hand, take a company like Apple. Part of their strength comes from the interoperability of the components in their ecosystem. Apple focuses on control, privacy and security, and the experience of having confidence while on an Apple product. Their organizational goals don’t lend themselves to opening up data to the world, which is why they haven’t pursued a material API strategy.  

Some of the companies we work with have the opportunity to expand their product by building on top of others’ APIs. What should people keep in mind when they are on the other side of the API relationship?  

Doing an assessment of how this will strengthen the product you are building should be the starting point. Is this augmenting an existing feature or product you have? Are you looking to build a new feature, but the underlying infrastructure to do this is outside of your core competency or too resource intensive? Questions like these can help companies determine the trade-off of building vs partnering.  

Especially if it’s not a core competency, it may make sense for companies to outsource certain components via an API integration and focus finite internal resources on their areas of strength. Another, and often overlooked, element is the degree to which this API is core to the partner: Is this their priority or the main item for your partner? When things go wrong will they be there for you and can you trust that they will continuously invest to make their product better over time? The API should be one of their top priorities, and they need to have a sustainable business to ensure longevity of service. You don’t want to work to source a new provider once you’ve invested the resources to build on someone’s API. Durability, core competency and alignment to your goals are the things to underscore. 

For any founders wondering when the right time is to add your first Product Leader, feel free to reach out to schedule a conversation with Daniel or the team to discuss further.