Every good story needs a villain
In his twelfth article, Mark shares how he created a name and story for his new consulting practice by showing potential customers everything it wasn’t going to be.
In 2015 I met with corporate IT legend Ralph Syzgenda, who predicted that what we were doing would be commoditized by 2018. This advice incentivized me to always remain fresh, reinventing ourselves every three years. So in 2017 we decided to build our own consulting practice to be able to work on the most valuable part of our clients' challenges. This was one heck of an ambitious reinvention.
Our idea was to bottle the way startups work and sell this to large enterprises. It was still a pretty vague concept. We weren’t even sure how to talk about this with clients and prospects, including how to engage with them to market test and refine our idea. To start those conversations, we needed to nail down a few things:
What was our elevator pitch?
How could we get our whole client-facing team to deliver this pitch?
How would we back up the high level idea if asked for more detail?
We had two techniques in our toolbox that if combined, helped prospects and clients really understand what we were talking about so that they could engage with us in a conversation:
We gave our idea a name
We gave our idea an opponent
1. We gave our vague idea a name
We started to call our idea “Product Mindset” or “Product-minded Development.” This was meant to capture the idea of taking all of the ways that a startup develops a product and apply them to the creation of enterprise applications. At this point it was still a vague idea, but I’ve found that as soon as you can name something it begins to take on a life of its own.
2. We created a villain for our story and gave it a name
If this is a great new way of doing enterprise development, what was the terrible old way? We came up with the name “IT Mindset” for the current or “old” way of doing things. This allowed us to tell our story through a direct comparison.
We then put together a single slide to tell the story through this comparison. In one column, we put “IT Mindset” and in the other column we put “Product Mindset.” We then laid out how the two were different.
Objectives
First, we talked about the objectives of each. For the IT Mindset, the objectives are typically to cut costs and lower risks. There was also an alarming implicit objective in a large enterprise for IT teams - to not get fired. For the Product Mindset, we captured typical objectives in a startup - to aggressively grow revenue and become a market leader. When we presented this comparison, we emphasized that to grow revenue and become a market leader, you typically have to deliver a great user experience. So people walked away at this point seeing the comparison as “don’t get fired” vs “deliver a great user experience”. This turned out to be a compelling argument.
Team Structure
Second, we investigated the structure of the teams in the two approaches. For IT Mindset, we typically saw a fractured team. The owners of the business results were in one team (often brand managers or product managers on the marketing or go-to-market team) and the technologists were on the IT team, reporting to a CIO. Having them on separate teams caused no end of alignment and communication problems. We contrasted that with the typical Product Mindset approach of a small, cross-functional team. In the ideal team, you’d have a business owner (product manager), a UX leader, and technologists all working closely together to understand the customer’s challenge and come up with creative ways of solving it.
Team Skills
The third area we discussed was the difference in skills required for the two approaches. For an IT Mindset, you typically needed team members with deep technical expertise in a specific area. They usually weren’t measured by anything other than getting their features built and delivered. For a Product Mindset, you needed what we called “T-shaped people.” The idea was in the market already, popularized by IDEO. The concept is that you want people with depth in a specific skill (such as engineering) for the downstroke of the “T” but also with the capacity to work cross-functionally (the cross stroke of the “T”).
Schedule and Scope
The fourth area we talked about was the difference in defining schedule and scope. In the IT Mindset, you’d define scope in terms of a specific set of features and declare victory when they’re done, regardless of whether the business outcome had been achieved. In a Product Mindset approach, you’d define milestones which are a portion of the business outcome. For example, if the business outcome was to raise conversion from a shopping cart to purchase by 20%, you might set the first milestone as improving the conversion rate by at least 5% from the baseline.
Give it a name and it gets a voice
We hadn’t fully defined our new concept yet, but by naming the idea and comparing it to the current (lesser) way of doing things our whole team could begin to engage prospects and clients in conversations and get feedback. In 2017, applying these startup techniques to enterprise application development wasn’t widely adopted. It turned out we were on the early edge of it and it has become quite common since then.
Tips to take away
Give your vague idea a name. Even if the new concept is not fully developed, there is a lot of power in naming it. If you pick a descriptive name, people will want to engage to better understand what the concept is that you’re talking about.
Engage with customers and prospects as soon as you can. With many ideas, you start out with something that you hope will be valuable to prospects and clients, but you’re never really sure until you get their feedback. As soon as your concept is fleshed out enough to describe it, I’d recommend getting a feedback loop going.
Utilize comparisons to highlight the strengths of your new concept. Comparing our Product Mindset to the then popular IT Mindset not only helped us clarify our own thinking and what we meant by our new idea, it also showed others what we were proposing so we could get feedback.
