Building a new consulting practice from the ground up
In this article, Mark is joined by his colleague and friend to share how in 2017 they helped expand Nexient from engineering services provider to a multi-faceted consultancy.
I’m excited to welcome Andy Lin as this installment’s co-author of the Consulting Balance. Andy was instrumental in moving Nexient from being seen as a staff augmentation provider to a key strategic partner. He is one of the best consulting minds I’ve ever worked with and now leads Provoke Solutions.
When Andy joined us Nexient was at a pivotal point in its growth. From the feedback we had received it was clear we needed to provide more strategic services to our clients. Up to this point, we had a great practice doing only engineering work, building what others had strategized and designed. Now we wanted to help implement the strategy and design too. Andy was instrumental in building this capability side of the business. Our concept was simple - capture the way startups build products and offer that as a service to enterprises.
It all sounded good on paper, but the reality would be far more challenging. How do you create a services offering from scratch? We knew we’d need a world-class team, a methodology for how to deliver services with consistently high quality, client case studies, and a set of tools to use as we did client work. But putting this all into practice, while running the current business, required some high level help.
Luckily Andy, who had recently joined the company, had moved his two prior firms (a Bay Area based boutique consultancy and Appirio) in a more strategic direction by building a successful user experience practice. I knew he had what we needed to build this new practice into our business.
To realize our ambition we first had to figure out the answers to three key questions:
What’s the difference between designers in an agency context building new brands and product designers in a startup building product?
Could we get product managers to be great consultants?
How do we move from selling teams of engineers (or individual engineers) to selling whole product teams?
1. Agency vs Product Designers
Design agencies are consulting firms for multiple clients that outsource their design requirements. Product companies create a specific product that serves a particular function for a certain audience. Both outfits design and build for specific needs but they differ in how they function. We wanted to investigate these differences in order to figure out how to build a product design service offering.
We started out with a day at the whiteboard comparing the process for design agencies with that of product designers. From the conversations we’d had, it sounded like the way design agencies approached a UX problem massively overlapped with a product designer’s approach. We went through what both disciplines called their respective approaches and the various tools, processes, and outcomes they used.
It’s at this point I’d like to hand the narrative to Andy, whose knowledge and experience with this is superior to my own:
[Andy]
There definitely were, and still are, a lot of overlaps in terms of digital agency capabilities and the product design process. The one notable difference was that Agile (an incremental and iterative development process) was a central part of our offering. This meant we had to adapt the design process from being too serial/“waterfall” (linear and sequential project management) to meld into Agile more seamlessly. All of the other usual tools, processes, and artifacts - such as mood boards, personas, journey maps, wires, and design systems - mapped really well between design agency and product design.
Another learning, that I brought from my previous experiences building agency capabilities, was that the term “cross-functional” had to go beyond the words. It had to be lived. The design team needed to have sufficient grounding in technology and engineering, and the engineering team needed to understand and appreciate some of the more nuanced priorities that the agency team valued. Without this, I don’t believe the success we had at Nexient would have worked, as clients would’ve quickly picked up any internal dissonance between the design and engineering resources.
2. Product Managers as Consultants
[Mark]
The next question seemed more challenging. How do we build a practice of consulting product managers? In this area there were fewer examples of successful consulting practices that we could model our new practice on. Would we be able to recruit product managers (who typically like to own a product) as consultants? Can product managers even make good consultants? It took a while to work through these issues, but ultimately Andy and his team built a successful product management practice that was critical to our success in building an offering of product teams.
[Andy]
First we had to build the practice with people who had strong product backgrounds, but it was equally important that every hire we made across all of our disciplines also had strong consulting acumen. At the time this was not common so hiring the first few members of this practice required us to prioritize product management backgrounds, and try to make a bet on people who we felt had high potential as a consultant.
One of our very first hires in this practice had zero consulting experience but a really strong product background. What made her stand out, was the way she described her experience and how it really had strong resonance with consulting speak. This included emphasis on understanding the end-user or customer need, prioritizing value and time to market with the right parameters, building in feedback loops, and keeping stakeholders involved - all consulting notions but in a product management context.
3. Selling Whole Product Teams to Clients
[Mark]
The final question addressed if clients would even be willing to outsource product management (typically one of the most strategic areas of the business). Enterprises need to have a pretty compelling reason to invest in strategy and project management externally. One way we were able to convince clients to bring in our product owners was to ask them if their product managers had enough hours in the day to get everything done that was assigned to them. The answer was always that they didn’t have time to get their jobs done and 100% of them could use help in the area of product management. Andy and his team created an offering that solved a client's need to get help in product management without overstepping what clients would be comfortable with.
[Andy]
We needed to come up with an offering and go to market that would balance what should really be kept in-house from the client’s perspective with what could be outsourced and what pain it would address for our clients. We discovered an opportunity through an interesting discrepancy. Most of the clients we worked with were implementing Agile in some way or form, but the titles for the product leads were Product Managers. Agile doesn’t use this term. It instead has a role titled “Product Owner.” We crafted a position where (client) Product Managers took an inside-out approach, managing the strategic aspects and (our) Product Owners were inside-in, translating the strategy and product vision into consumable bits of information. These were captured as User Stories in Agile parlance. Our hypothesis was that clients would appreciate enabling their Product Managers to remain strategic and free them up to more effectively manage what was typically a portfolio versus a single product. The nitty gritty day-to-day detail could then be outsourced via the Product Owner role. And it worked.
The last thing I’ll call out is that the consulting practice needed to not just deliver work, but also take up the mantle of thought leader. This wasn’t done in isolation of Engineering of course, but the market responded well to leading with solutions to business problems instead of leading with technology as the focal point of thought leadership. So in addition to delivering services, the Consulting Group became a “farm” system for Consulting Directors and Client Partners, who were ultimately responsible for P&L and client expansion. This drove and fueled Nexient’s growth at least in part by establishing ourselves as strategic partners, that then pulled in implementation services such as Engineering.
From well-planned ambition to successful reality
[Mark]
Although it seemed daunting when we set out to build these new services, they turned out to be successful in the market, growing to hundreds of people strong. Even more importantly, they moved us to a position where our clients viewed us as advisors of what to build and why. What’s more, we were now a key partner in deciding how to build out the software, which drove significant growth in Engineering too.
One side effect I didn’t realize we’d see early on was that as we moved upstream into product management and design, our developers would also become indispensable to our clients. We always involved technical leaders throughout the process so we never designed anything we couldn’t build. This forced our whole team to raise their game and work in a cross-functional way, which our clients clearly found more valuable.
Tips to take away
Hire great talent – none of this would have worked if we hadn’t brought in Andy to lead the process and if he hadn’t subsequently hired successful leadership teams. Boutique consulting firms are only successful early on if you hire world-class talent.
Push your company (and yourself) to do things that haven’t been done before – when we set out to create fresh strategic and design solutions, we were pushed out of our comfort zone. First, we had to figure out how to adapt an agency model for design to the product approach. Second, we had to navigate the uncharted territory of creating a practice of consulting product managers. Taking it step by step, we were able to figure it out over time, but we didn’t really know where we were heading when we started on the whiteboard.
The details matter – Andy and I both have a lot of experience as practitioners. We’ve built a lot of software in multiple contexts. That allowed us to keep digging deeper as we thought about the actual process and tools that would be required for this to work.
