In this article Mark shares how he developed a strong methodology for Nexient called “Product Pipelines”. This methodology was created to help his enterprise clients quickly develop successful customer-facing software by ensuring all aspects of their business worked together through the pipeline from the outset. He tested the concept behind this methodology with 20 clients at Nexient’s third Nexus conference in 2019. Read on to discover how it was received.

How to build a winning methodology in professional servcies

Methodologies are inherently boring. When you’re in the business of doing and delivering, trying to adhere to an abstract set of rules can be challenging.  

But methodologies are important. They provide a logical framework for how to do something unique to your business. If they are done well, they can actually add a lot of value to a consultancy. However, if they are done poorly, they are rarely looked at and infrequently used.

While running Nexient, I took a lot of calls from investment bankers. I’m always curious to learn about new things and I didn’t really understand how selling a consultancy worked. One of the things I learned from these conversations is that if you sell a $20-$30m consultancy, almost all of the value is locked up in the people running the firm. If you cross $100m, the acquiring company believes you have a created a machine that can survive the leadership departing.

I believe that having a great methodology (however boring) is the key to building a machine like this.

What we wanted our methodology to be

In 2019, with our third Nexus conference approaching, we had the deadline we needed to finish this methodology (or at least the first version of it). We wanted to use our conference as an opportunity to present our methodology and get our clients' honest feedback.

Our aim was to capture how startups developed software and map this to an approach for large enterprise clients. We were trying to encapsulate a number of things in this methodology:

• We wanted clients to shift their focus from risk aversion and cost, to revenue growth and market share
• We wanted them to break down the walls inside their organizations, really getting the business and technology people to work together
• We needed our methodology to be memorable and something that would resonate with both our team and our clients’ teams
• We needed to capture and build on all of the details required to make this methodology a very real approach to software development.

Testing our methodology

Without going into the details too much (I’m trying to write about methodologies here and keep it interesting), we decided to call our methodology “Product Pipelines.” The high level idea was that we wanted to teach our clients to have multiple groups within their companies that could take a new concept and rapidly move it through all the stages required to get it into the market as a successful product or service.

We outlined the stages of the pipeline and demonstrated what would make the organization successful going through these stages. We did this by showing a cross-section of the pipeline with the core cross-functional team that powered our approach. This team would be equal parts Product Management, UX, and Engineering.

What really made this whole approach resonate with our clients was when I highlighted a fascinating challenge I saw in almost all of their organizations. Both the business side and the technology side would do a ton of work to drive world-class execution. The business side (marketing/brand management) were experts in digital marketing, doing lots of A/B testing, experimentation in the shopping cart to improve conversion rates and all of the other things you should do. The technologists had studied Agile and implemented all of the ceremonies. They had the basics of the process down and talked a great game. But even with all this work, the business and technology sides did not team up. The technology teams would “demo” their products every Friday to a tech audience and then deploy them to a test environment. Every four to six weeks, the business people would come in and try out the software. They’d log a ton of defects for things that were now expensive to fix. If they'd just come to the weekly demos, these issues could've been addressed far more efficiently.

When we described this gaping hole in the process to our clients at Nexus, I really wasn’t sure how they'd react. Fortunately they agreed that it was something they were struggling with and if our methodology was designed to help them combat the problem, they were all in.

Some of our process

The methodology itself was way too much to share with clients at the conference (and keep them awake) or for me to share with you here (and keep you reading). What I can describe though is how we built it out and what it looked like.

We used a wiki to put the whole thing together. It ended up being hundreds of web pages, covering all the activities we believed were required to consistently take ideas through every needed stage of research and market feedback to get them to launch as successful products or services. We also captured templates, example documents, and FAQs for how to execute the hundreds of steps that were described.

My vision was that the whole thing would be a living, breathing document like Wikipedia. I’m always amazed at how quickly that is updated. It literally seems like minutes after a major event has happened it shows up there as history. We never achieved this level of activity, but we did get to a document that the team continued to build on as we did more and more engagements.

Some final thoughts

For anyone who has read about our first or second Nexus, this third one confirmed that we had created something lasting. We had more than 20 client attendees and three technology partners come to share what they were working on. The arc of the three first Nexus conferences mirrored the development of our differentiation – a product approach to enterprise software development.

Distilling my learnings from this conference, and the development of our methodology, I can say this:

1. Methodologies are at the core of the most valuable consultancies – Every really successful consultancy I’ve worked with has a strong system and process at its core. Talking to the bankers helped me understand the value of this to a company. Focusing on our Product Pipelines methodology was a key ingredient to getting Nexient over $100m in revenue (and into the top 200 firms out of 10k according to Gartner’s numbers).
2. To create a valuable system, client feedback is key – As we worked on it internally, we had lots of conversations where the right answer wasn’t obvious. Having our client executives so closely involved in the process helped us make sure we got it right.
3. Look for the problem you’re solving – It's always important to be able to articulate what problem you are solving. For us, it was the shift in how enterprises developed their customer-facing apps. We wanted to get them to focus on a great experience in order to drive new revenue and greater market share. Seeing how they were struggling with this gave us a clear problem to focus on solving.