A day in the Life of Joe Leech, Product Consultant
Joe Leech is an expert in product design strategy, UX and applying psychology in design. He’s recently written a book, “Psychology for Designers,” in which he focuses on recognising and using psychology as a design tool. He’s now a product consultant who works with a range of companies: “I plug into companies that have delivery teams, and I advise the teams on what they should do and in what order.”
No Magic Bullets
Joe’s role as a product consultant means he needs to do his homework thoroughly before he even walks into a client’s office. “I often have a pre-meeting with a pre-filled document from the client, pinpointing the specific problems they face; from that I can figure out what’s going on.”
As part of his role he talks to the different stakeholders in companies – CFOs, senior business people, and delivery teams – and it’s a source of frustration for him that they typically don’t speak the same language. “Executives are intimidated by Agile,” he says. “I help the organisation talk ‘product’, getting teams ready for delivering goals and for linking strategy with product by translating business strategy into what it means operationally in the business.” And he’s found that there is no single solution or framework which solves his clients’ problems. “There is no magic-bullet framework […] anyone who claims they have one single tool is kidding themselves.” Some organisations like to work with users face-to-face, while others prefer video recordings of user testing, and still others might like in-depth background research.
“Frameworks are descriptive and not prescriptive. A framework is only useful for showing confidence in the conclusion I come up with.” According to Joe, organisations vary in wanting to use a framework or in needing a quick decision. Still, he has found that “Jobs To Be Done” is a concept that most feel comfortable with: “It’s a bit frameless, it’s a bit pragmatic. It’s in the Harvard Business Review, so executives like it, and UX people like it too”.
You’re the Glue
Joe believes that all product people must first and foremost be relationship people: “Product management is about building relationships and sitting across the teams in the business: this means being able to go and talk to sales, marketing, customer services, customer support. If you are sidestepping, you’re not a good relationship person.” The short explanation he gives for product people is that “you’re the glue that brings everything together”.
What does he most enjoy about product management? it’s the opportunity to react quickly to problems and deliver necessary changes. He acknowledges that product management is difficult to teach and that the role often comes with experience: “The challenge with academic design is that it’s already three years behind the industry. It gives you a good grounding, but not the skills.” On the bright side, Joe thinks that the one aspect that product people can formally learn and bring to the table is business knowledge.
In Joe’s experience, nobody does Agile the same way. “Different companies always have their own way of doing [Agile], and that’s fine because they do things in a certain way for a reason.” Regardless of this non-uniformity, he says that the Agile process isn’t broken, and rather it’s structure that companies need help with: large organisations don’t necessarily understand what a product manager does, and therefore the company structure does not allow for them to work properly.
Joe emphasises the difference between product owners and product managers: “A product owner can’t be and isn’t a good product manager. A good product owner doesn’t have experience in delivery and Agile: a good product manager has experience in Agile but no experience in making the right business plan and presenting it to the CFO. The same applies to UX people.”
Big vs Small
“Startups are good at speed, big companies are good at making good decisions,” and startups and enterprise have a lot to learn from each other, he believes.
Startups are lean and for them fast actions are crucial, but their people often lack the knowledge or skill to make the right decisions, he believes. “Startup founders are especially hard to work with because the company is their baby. They hate formal processes because it gets on the way of getting going.”
But large corporations focus on share price, which means making the right decision can take a long time. “I often get involved with big companies when they have built something and it’s broken,” Joe explains. Such instances bring a lot of time pressure because shareholders worry about share prices. He works first on fixing the immediate problem and then looks into the root cause of the issue which, most of the time, he finds, lies in the organisational structure. “There are a lot of knee-jerk decisions because managers or teams have previously made bad choices.”
“Companies operate either by numbers or stories, so I select appropriate prioritisation tools and frameworks for them. If you use a framework that doesn’t fit, [the company] won’t use it, and there’s nowhere to go.”
With clients that are numerically focused and enjoy giving scores to ideas, Joe mostly uses the PIE framework. The PIE framework considers three areas of relevance: potential, importance, and ease. These three areas are ranked on a score out of 10 and are prioritised in descending order by taking arithmetic averages of those scores.
Some companies prefer stories over figures, and for them Joe uses the KANO method – it divides (product) ideas into three groups: basic expectations, satisfiers and delighters. “If they pay you to come in and tell them what to do – that works too,” he says.
Sharing Failures is Success
“To be a successful product team you need to treat sharing failures the same as sharing successes,” Joe says. Again he highlights the importance of company structure. “In a top-down structures you have men in grey suits telling you what you have to do. In bottom-up structures, product teams conduct research and say what they want to do for the next year.” He observes: “Organisations are either too top-down with no knowledge of what’s going on, or product teams have a lot of strength in an organisation, and managers are scared of the product teams and don’t trust them. You need a balance.” He thinks that the best way to achieve that balance is communication on why things have worked or not.
To share success, you first have to understand it. “If success and failure are defined, it’s easy to talk about them.” He continues: “Good teams measure stuff. If measures are set, the whole team will work towards to the same goal and deliver the right things.”