Why We're Firing a Top-Tier Product Development Firm


We hired a top-tier product development firm, and now we're firing them for a variety of reasons.

10 minute read


Some of the work I’ve been doing recently has been with what’s known as the Business Development branch of a large company. Basically, it’s like a handful of small startups with a Fortune 500 budget, or something I’ve come to learn is called “corporate innovation”.

One of the benefits of working in this environment is the incredible access to resources our teams have. I’m used to the early-stage startup world, where there’s no money, no time, a million things to do, and everything is on fire, whereas the world of corporate innovation is very, very different.

For one project, we decided we needed some additional help, so we decided to hire an agency to help us get an MVP up and running.

Nobody Ever Got Fired For Buying IBM

Go with the internationally acclaimed option

We interviewed about a dozen firms, including local options as well as national/international agencies, and weighed the pros and cons of working with each. Some simply couldn’t offer the bandwidth or the expertise we needed. Others we felt weren’t paying attention to our needs and wouldn’t be a good fit for the phase our product was in.

While we said no to some extremely well-known and highly reputable companies, we ultimately went with one that had a great reputation/track record, lots of really exciting examples, and that we were excited to work with. While none of us had any experience working with this company in the past, we felt good about it. After all, nobody ever got fired for buying IBM.

Part of my role on this team was to make sure these agencies were passing the “sniff test”, and to pick one that would be the best fit for what our product (and team) needed, and I was fully confident in moving forward with this partner.

Bait and Switch?

An unfortunate circumstance

Things got off to a bit of a rocky start, as scheduling around the holidays is virtually impossible, but there isn’t much one can do about that. There was something that was particularly interesting about this experience, though.

The individuals we were talking with throughout the courtship process seemed to completely understand where we were, what we were looking for, and were on board with the rough outline I (as the in-house designer) had laid out. When asked, they reassured us that this was in fact the team we’d be working with. However, when it came to scheduling, there seemed to be a few conflicts, and after having to push back the start date, we also learned that these team members wouldn’t be available any longer.

I don’t want to take anything away from the individuals we did work with, but this kind of felt like a bait-and-switch on our end. Not only was there now a disconnect between everything we’d talked to this team about and the new team, it just didn’t quite feel right. Cue foreshadowing.

Culture Mismatches

Short work days, every holiday off, laid back attitudes

Once we locked in a start date, things seemed to be moving smoothly. As is typical, we kicked off our engagement with a week-long Product Design Sprint on-site in one of their offices. It was a great opportunity to get all of us out of our typical environment and give us an excuse to focus exclusively on this project, to (hopefully) learn something about their process, and obviously to built rapport with the team so we could work effectively going forward (especially considering it would be remote).

Our half of the team was totally jazzed up to get this project moving and to hit the ground running, so despite one of the worst travel days of my life (the perfect storm of a computer glitch and a winter storm) which resulted us getting into town Monday afternoon instead of Sunday night, we were ready to put in long hours and have something we were proud to show off at the end of the week.

Any design sprint is going to be an intensive, exhausting experience, and I’m all for working smarter versus harder, but our initial experience wasn’t exactly what we expected. It seems the standard was to start work around 10am and leave around 4pm, all while taking about an hour for lunch. This pattern continued (if not intensified) after the sprint, and was a major sticking point.

Our culture was more of a ~830am-430pm work day, plus extra time if you needed to stay late or work from home that evening. They also embrace Google’s “20% time” idea, meaning they were only working/billing 4 days a week, taking every Friday as a growth day. If you looked at the difference in hours per week, our team was putting in 40-50 whereas it seemed they were doing almost half that.

Another thing that seemed shove a pretty significant wedge between us was actually the reason we had to reschedule in the first place: holidays. We didn’t even recognize that our initial start was MLK Day. After we’d originally agreed on that date, we heard back a week or so later (after we’d already started booking travel, no less) that we had to change. They also didn’t work President’s Day, either, which along with the 20% time thing meant we had a few 3-day weeks.

Further exacerbating these scheduling woes were some differences in communication style and tone. Not to say we’re all hard-asses, but the laid back attitude that our partners espoused was often at odds with our desire and urgency to move the project forward. One of our colleagues (who wasn’t even on this project) was walking by during one of our daily standups (via Google Hangouts) and afterwards commented on their tone, calling it borderline unprofessional. Another teammate who wasn’t directly involved with working with them often made references to Portlandia.

All of this aside, there was one other culture shock in terms of tooling. Our team was familiar with using Asana, JIRA, Box, Outlook, AWS, and Github. Throw in some Google Analytics and Mixpanel and that’s about all we needed. Throughout our engagement with this partner, we were suddenly using Trello, GrowthHackers, FormKeep, Segment, Netlify, Google Drive, Redpen,…the list goes on. Mind you, this is still corporate innovation, meaning a lot of the tools we use have to be approved before we can store IP or PII in them.

Quality

It shouldn’t take a week to build a static landing page

Another surprise (and, at the end of the day, what was ultimately the breaking point) was the overall quality of the work. None of my teammates are product designers, nor do they have much experience working in tech at all, so while they were excited to see what a design sprint was like, I was looking forward to working with (and learning from) some of the best in the business. The experience we had was altogether different than our expectations.

One of the big differences between our team/project and I’m guessing a lot of the other work they do was the degree of empathy work and background research the team had done. I joined this project over a year into it and it took me months to digest and distill what they had learned, so I’m not saying it’s an easy task. That being said, our team came in with a lot of expertise and knowledge around who our target users were and what challenges they faced, which I would’ve assumed would help us move quickly. Instead, what we were faced with was push-back at almost every step.

We came out of our design sprint feeling a little lost. The target (and, thus, problem) that our partners wanted to focus on wasn’t at all what we’d come into the week with (which isn’t necessarily a bad thing), and overall there seemed to be a lot of skepticism on their side. The next few weeks saw extremely slow progress peppered with discussions about how to move forward (and how to do so more quickly, at that).

We came into the engagement assuming we would follow their lead in the product development process, doing what their expertise suggested. That wasn’t working, so we tried giving them direction instead. Not only did that also not work, but it seemed as if they didn’t trust our research and the conclusions we had drawn from it. As a designer, I would love to spend as much time as possible doing research, but there’s a point of diminishing returns, and one of the things we laid out at the beginning of the courtship process was a bias toward doing.

Above all else, though, the speed and quality of work just wasn’t there. Once we convinced them to actually take action instead of focusing on research, we laid out a plan together to create a few simple landing pages and run a few Facebook/Google ads to gauge interest. These pages wound up taking over a week to write copy for, design, and implement, and that’s due in no small part to the tools selected (surprise, surprise).

Each landing page went through a process of low-fidelity wireframes, high-fidelity Sketch/Photoshop comps, and then built out using Middleman and Bourbon/Neat. At one point it took me fifteen minutes to get all the dependencies installed and my development environment setup only to make a 30-second change (which, mind you, was something our developer told me would take too long to change, and lead me to one of my favorite Slack exchanges ever).

Now What?

Look again? Bring it in house?

So we came to the conclusion that we needed to cut our losses and fire the agency. It wasn’t an easy decision considering we still need to move quickly to meet our internal deadlines, but ultimately the amount we were paying and the output we were seeing just didn’t make sense. We even had the sense that we could move more quickly by ourselves, which brings me to another interesting point.

If you remember back at the beginning of this post, the reason we wanted to look externally at all is so we could move more quickly. Between myself and some of my teammates, we have the skillsets needed to at least get through the first few months of designing, testing, and building an MVP. Part of the discussion of what to do next was whether we should just move forward ourselves and get as much done as possible.

Ultimately what we’ve decided to do is somewhat of a hybrid approach: instead of hiring a firm to do all the work, we’re looking more toward a development partner that can take care of the heavy lifting and allow us to focus on design, strategy, branding, marketing, and all the other things that come along with it. Basically, let someone else worry about the details of implementation and we’ll handle the direction.

What I would love would be to have an entire team on the inside that we could partner with for these types of things. If you’re in corporate innovation, and you foresee this being something that the group/company needs to do, it makes sense to bring as much of it in house as possible. We’ve already had a few different teams hire a few different agencies, and aside from it being horribly fragmented and disjointed, it’s also incredibly expensive.

Bringing all of that in house would increase quality, decrease turnaround time (especially considering you would eliminate all sourcing and negotiation time, which has easily added months to our timeline), and decrease costs. This is the plan I’ve been advocating for us to take and is by far the most common recommendation I make to others in similar circumstances.


Do you have similar experiences to share? Are you in a similar situation, trying to decide how to move forward with a project and who to hire? Trying to build your own in house team? I’d be happy to talk more about it (and hopefully be able to help)! Let’s chat.



All Meta posts: