Can you outsource building products?

Conventional wisdom firmly states that you can’t.

In fact, thought leaders like Marty Cagan, go even further.  They believe that not only building products and outsourcing don’t mix.  But, if you are a product manager in an organization that does leverage outsourcing, you should find another company to work for.  

The problem with this philosophy is that it ignores reality.  

Whether we like it or not, outsourcing is here to stay.  And while the “no outsourcing” mantra works for the digital startups in Silicon Valley.  The majority of Fortune 500 companies do outsource and will continue to do so.  

The question then is, how do you make it work?  

To help us figure out how to build great products with an outsourcing provider, I interviewed Eddie Pinto, VP of Product at Alight.

Eddie Pinto is the Vice President of Product Management and Strategy with Alight, where he is responsible for building HR Enterprise B2B2C solutions.  

Eddie is passionate about launching 0 – 1 products, delivering industry-leading experiences, and building empowered product teams.  He is also one of the few product leaders who has made outsourcing work. So that he and his team can continue to launch products that delight their customers. 

What follows below is a condensed and lightly edited version of our interview.

Eddie, let’s start with a quick overview.  Can you tell me more about Alight?

Eddie Pinto:  Mustafa thanks for having me.  I am glad we can finally do this.  I am really looking forward to it.

As for Alight, we build and run enterprise software for HR applications. So think Health Benefits Administration, 401K, Reimbursement accounts, Pension administration, HR, Payroll, Wellbeing, employee engagement, etc.

We serve 36 million users in the US, including 70% of the Fortune 100, and do over $3 billion in revenue. Our products have won every industry accolade of note, from Gartner to Forrester, IAOP, NelsonHall, and Everest Group.

That is pretty impressive.  Thanks, Eddie.  

One of the things that I find fascinating about what you have done, is that you heavily use outsourcing providers to help with product delivery.

This, as you know, goes against the grain of one of the many fundamentals of building products.  Now before we go into the how, let’s start with the beginning.  Why did you end up going with an external service provider?

EP:  Yes we are definitely going against the grain.  But for us, it was all about attracting and retaining talent.

Rolling the clock back, Alight had been growing our development presence across various global campuses, and by 2015, we had over 500 engineers in India. However, since very few people outside the HR industry had heard of us, we found it hard to attract and retain top talent. The best engineers wanted to work for the Wipros, Satyams, and Tatas of the world. Especially for young talent, we learned that brand recognition played an outsized role in choosing an employer.

It may sound crazy, but our employees were telling us that it was harder to get a car loan, an apartment lease, or a credit card because we weren’t a household name. (Laughing) One engineer even told me that our lack of brand was affecting his marital prospects! His soon-to-be wife didn’t want him to meet the parents. They wouldn’t approve of him since his company wasn’t a familiar name.

Even when we paid more, it was just hard to find the right people. This was a big factor in our decision to rebadge our India colleagues and move our India captive center to a third-party service provider. We got to keep our talent, but they now belonged to a much larger, well-known company. One that could attract the right talent to help us grow at a rapid pace.

And how is that model working for you?

EP:  We had our growing pains, but at this point, the teams are thriving.  So much so that we have since expanded to three different global software development partners; in addition to an onshore partner organization supplementing our in-house developers. We even launched our flagship app, which has 1.25 million downloads, a 4.8-star rating in the Apple App Store, and is regularly a top 50 business app, with developers from two partner organizations and in-house developers collaborating closely with our Product and Design teams.

Wow, you have really leaned into the model.  Tell me more about the growing pains you mentioned early.

EP:  Like most things, it took hard work and dedication.

Even with the advantage of working with a lot of the same people — and the infusion of talent that joined the team as we grew — some of the pitfalls of outsourcing started to creep in.

The quality of the software we were shipping started to go down.  There was a palpable loss of creativity and innovation. Our partners had the misconception that order taking was the highest level of service, when in reality, we needed engineering to be equal partners in product discovery, challenging our assumptions and proposing more feasible solutions.

While we had worked hard to formalize processes across Product, Design, and Engineering, the organic conversations that led to creative solutions weren’t happening. We had drifted apart, the teams felt less connected to our mission, purpose, and vision.

Eddie, so far you have described pretty much every outsourcing relationship.

EP:  Yes, you are probably right.  

One more thing, before we go on.  This was not overnight.  It took time for things to erode.  And we only started to really notice it a year or two into the journey.  

So what did you do to pull out of this death spiral?

EP:  A few things.

First, we realized that over time that our teams had fallen to the bottom left of the chart. Where the dev teams were in order-taking mode. And by the way, the fault was not just theirs. Our product managers were to blame too. Instead of sharing context, purpose, desirability, feasibility, and viability, the focus was on tasks and dates.

Once we knew where we were, then we started to experiment with how to get to the top right. We wanted our teams to have consistent, differentiated results. We wanted our engineers to have a deep understanding of the vision and purpose, challenge assumptions, suggest alternatives, and become equal partners.

Agreed. Too many organizations find themselves in a similar “order-taking” mode. What did you do?

EP: Four things actually.

First, was leader buy-in and partnership across the organization. We used the chart above to talk about the problem, why we needed to solve it, and where we wanted to go.

Second, we purposely started small. We picked a team where our PM and engineering lead could be champions of change. Not just in adopting new ways of working, but in being vocal advocates in the organization. And then recognized their successes and the process that led to those successes.

Third, is removing the barriers to collaboration. Our agile processes had more handoffs, lines, and boxes than we had people in one dev squad. It was getting in the way. So we worked with the team to understand what parts of the process were driving value and we pulled everything else out. For example, we removed our partner’s engagement managers from calls if they were limiting healthy debate.

And lastly, we gave our dev team a seat at the table. We invited them to town halls so they hear the same messages as the product team hears. We also included them to listen in on customer interactions, user research, report outs, etc. The goal was to keep them as connected to the customer as the product team so that they have the proper context.

Another factor was leader buy-in and partnership across the organizations. Of all the actions we took though, these three stand out.

Did that work?

EP:  Slowly but yes.  

Once others started seeing one or two teams doing things differently.  They too wanted to be part of it.  They were saying hey, you know, maybe, maybe I could do this too, or there was a conversation that would happen organically, where that person would go and reach out and say, How did you go about doing this? I want to do that too. 

Which was good.  Because it was organic. And less about this leadership mandate of this is the way that we’re going to work.

Organic is great.  I am curious, how did you personally end up promoting these behaviors?

EP:  Of course.  Maybe a bit too much sometimes (laughs).

I would join calls and if I saw an anti-pattern, I would model the behaviors we wanted or try to encourage debate.  When a PM asked, “hey, who has questions” our engineers remained silent. We knew this was because they felt leaders viewed questions as failures to understand when in reality we wanted those questions to get to richer solutions.

So, when they saw someone like me asking questions or encouraging the team to suggest ideas, it changed expectations and the flow of the conversations.  It only takes a couple of calls before it becomes natural and jump-starts the collaboration.  

You and I both know that team structure plays a big role in product development.  Did you end up changing the structure of the two teams?

EP:  The wild thing was that the structure was there all along.  The hard part was the process we had put in place that was getting in the way.  Too many processes were killing the natural collaboration that needs to happen.  

Now that you have fixed your relationship with your service provider.  What made you decide to add others?  Why not just stick with one?

EP:  With this provider, in particular, we were always in some type of contract negotiations every year.  And while I get it, it is very distracting.  I mean, at the end of the day I need to ship the product.  

So that was part of it.  But the other part was just about access to talent.  We wanted more developers who understood open-source technologies.  Our first partner did not have it.  So we went and found others.

The other was access to certain expertise.  For example, building product for the US government is quite different.  So we found a provider that is an expert in that.

The good news is that once we perfect the model with our first provider.  We can export it to others.  And that has given us a lot of freedom to expand quickly without taking on too much risk or headcount.  

And how did you manage the issue with rotation?  Every outsourcing vendor keeps rotating the team.  How did you get around it?

EP:  That was the easy part.  It was part of the contract.  The provider cannot switch people without having a conversation with us.  Other than them leaving the company of course.  

Last question Eddie.  Any advice for product leaders who have to manage development through these outsourcing contracts?  Any key lessons learned you would like to share with them?

EP:  A few come to mind.

First, anyone who tells you it can’t work has probably not tried making it work.  But if, like us, you work on it.  I can most definitely work.  And not just that, but it can bring scale to your development teams with little risk.  Which, frankly, through economic ups and downs, has been very good for us.  We can onboard talent quickly; and ramp down without laying people off and everything that comes with that.  

Second, always start small.  It is important whenever trying new things out.  Because not everything will work.  But also it’s a good way to test out your operating model without taking too much risk.  And when it succeeds it can be your showcase.  

Third, and last.  Is that you have to go in with the right intent.  If it is about cutting costs, then be upfront.  And know that you are going to sacrifice quality and innovation.  If however, like us, it is about access to talent.  Then create a contract that works for you.  Our goal has never been purely cost. Rather, it was access to talent.  That is what we optimized for and reduced cost is simply a natural byproduct.

Eddie this has been very insightful.  Thank you for being a guest and sharing your experience.  It just goes to show that blindly following “rules” makes no sense.  Sometimes you just have to go against the grain and put in the effort to make it work.

EP:  Mustafa thanks for having me.  This has been fun.  And I could not agree with you more.