Roman Pichler ‘Exploring product strategy success factors through a Design lens’

Gerry: Hello, my name is Gerry Scullion and welcome to Bringing Design Closer, which is part of the This is HCD Network.  I’m a service design practitioner and trainer based in Dublin City, Ireland.  Bringing design into organisations is hardly every straightforward, it always comes with its own unique set of problems.  In Bringing Design Closer, the podcast, we discuss with thought leaders around the world, what has worked for them in enabling design revolutions to occur.  Whilst at the Leading the Product Conference in Stockholm recently, I caught up with Roman Pichler, widely considered to be an expert in agile methodologies and product management.

He’s a sought-after trainer and is an author of two books, most recently: Strategize, a product management book.  In this episode we speak about the role design plays within agile, often considered to be the silver bullet in enabling transformations to occur.  We chat about the roles of product management and what actually a product owner is, in Roman’s eyes.  It’s a great episode for anyone looking to better understand the role of agile and design.  Let’s jump straight in.  Roman Pichler, a very warm welcome to bringing design closer.  

Roman: Thank you, thanks for having me on the podcast, on the show

Gerry: I’m delighted to be here.  We’re coming live from Stockholm.  We’re over leading the product conference.  It’s fantastic.  I really enjoyed your talk this morning.  Give us the title of your talk again.  

Roman: Product strategy success factors.  

Gerry: Yes, that rolls off the tongue, doesn’t it?  

Roman: It does, yes.  

Gerry: There was loads to talk about.  I think our listeners would find great value in trying to understand, first of all, a little bit more about what you do.  We’ll come to that in a minute, but we’ll talk a bit more around the roles of product and product manager specifically and how that intersects with design teams.  Let’s go back to my first question, tell us a little bit about yourself, where you’re from and what you do?  

Roman: I’m based in the UK, in Buckinghamshire, just outside of London.  

Gerry: Beautiful part of the world.  

Roman: It is, yes.  I’m fortunate enough to live on the Chilton’s, so a few hills, which is nice to pop out and do some cycling or walking and running.  Yes.  I work as somebody who teaches product people and consults organisations, helping them asses their product management capabilities and improve product management.  

Gerry: Yes, nice.  I notice you do public trainings and private trainings, as well?  

Roman: That’s right, yes.  I run public workshops and then engage with clients to do some consulting and coaching.  

Gerry: You’ve written two or three books; I saw on your website.  

Roman: That’s right, yes.  

Gerry: Yes, which is fantastic.  One of the things that I really enjoyed this morning was the product vision board.  I know there’s lots of different types of canvases that people use.  First of all, tell us a little bit more about where that came from?

Roman: Product vision board originally emerged from the work that I was doing.  I think writing, well, an earlier book, agile product management with scrum, I was very interested in understanding how we can elaborate on the notion of a vision or a product vision, which used to be at least in the early scrum, literature fairly prominent.  That’s where the product vision board originally came from.  My initial idea was that a vision should, in a way, talk about user needs and it should talk about stand-out features.

I then later, once I’d come across Ari Greesewerk and his work in the lean startup context, I realised that actually it would be much smarter to separate vision and product strategy and clearly distinguish between the two.  I then, in a way, redefined the vision as the ultimate purpose, the positive change the product should bring about.  I really like to capture the vision free of any specific solution assumptions.  A little bit like a glorified value proposition, a generalised value proposition.  

Then have the strategy that is, in a way, a path towards that vision and recognising that often, usually, there’s more than one path that leads to the same goal.  That allows people, allows me to pivot to change the strategy and look for new strategies.  I think the example I was using this morning was an example I like to use in my work, if I want to develop a product that helps people become more aware of what they eat and how much they eat, then the vision will be healthy eating.  

It might be a digital product that maybe interact with the smart scales and a smartwatch, or it might be writing a book or selling a book.  It might be running workshops on mindful eating in order to help people improve their eating habits.  Different strategies can lead to the same vision.  Yes, so that’s a little bit of the historic background of the vision.  

Gerry: Of the vision board, how does it differ between the value proposition canvas?  

Roman: Yes, the value proposition…

Gerry: I’m sure you’ve been asked that before.  

Roman: It’s a nice tool by Alexander Ostoval.  I think what Alexander Ostoval realised once he offered the business model canvas, which is another great structure, another great tool and template, is that business models are ultimately only successful if the value that the product creates for the customers and users is strong enough, it’s compelling enough, then you create the value proposition canvas.  From what I remember, it encourages people to look into pains and gains and jobs that the product should do for the users.  

Gerry: Then maps it back to potential products.  

Roman: That’s right, yes, and builds a connection back to the business model canvas.  The product vision board that I offer is related, it’s similar.  In a way, I’ve asked myself, what is the simplest possible way to capture a vision and capture the related strategy.  I feel that the simplest way to break a strategy down is to say, well, who are the users and customers?  What is the need, or what are the needs that the product should address?  Therefore, what is the main problem or primary benefit?  What is the primary job to be done that the product should do for the users and customers?  What are the standout features?  What are the business goals?  

Gerry: Absolutely.  

Roman: Then that can lead onto elaborating the needs in whichever way that is meaningful or helpful.  For instance, using jobs to be done theory, or using human-centred design and working with personas and user goals.  You can elaborate the business goals by talking about a business model that allows you to generate value for the business and either reusing an existing one or adapting an existing one, or possibly investing in creating a brand-new one, which sometimes is necessarily.  Certainly, in the case of disruptive products.  

Gerry: Exactly.  What I really like about this one is, it’s very accessible.  The problem I’ve had with the value proposition canvas and the business model canvas, if you bring it into a low maturity organisation, the vernacular and the words that are being used are sometimes very hard for them to grasp.  Even though it’s only pains and gains, they’re like, “What is a pain and what is a gain?” With yours, you’ve broken it down into target group needs, product, and the business goals.  It’s very accessible.  I’d imagine it’s something that I’m actually going to use.  I’ll credit you, don’t worry.  

Roman: Nice.  

Gerry: I wouldn’t be in danger of doing that.  

Roman: No worries.  

Gerry: Which is good.  Look, it takes us onto another topic around the team structure.  You’d mentioned around product person, I thought that was really interesting, not to use the word product owner/product manager.  You mentioned, we need to give credit to Rich Morozoff, who also uses that.  

Roman: That’s right.  

Gerry: What’s the problem with calling product owner and product manager?  

Roman: The reason that I quite like to talk about product people and use the term product person or product professional these days is that I find sometimes the terms, product manager and product owner are used in a divisive manner.  I think there’s been a lot of misunderstanding in the product management community around, what is the job offer of product manager, what is the job of a product owner?  Is there a difference?  What’s the difference?  Different people have different ideas.  Different frameworks have stipulated or suggested different solutions.  

For me, personally, the way I’ve understood the product owner role is always essentially being a product manager in an agile scrum-based context.  That’s the way that I’ve described the role.  Some people have strongly disagreed with this notion.  You look at agile and agile scaling framework, like, say, for instance, where the product owner role is redefined in a way a very tactical role, of somebody who works with the development team and takes care of the products backlog.  Then a product manager is more a strategic role, more outward-facing.  

Gerry: It’s a different mindset, it sounds.  

Roman: It is a different mindset.  Whereas, the original idea in scrum is that one individual in a way takes care of the entire product and provides the context for cross-functional, self-organising, autonomous, empowered team to own the solution and run with it.  A different idea, different mindset.  Ultimately, I think it shouldn’t really matter what we’re called, what the title is.  I think what should really matter is that we focus on creating value for users and customers.  Allowing people to benefit from an asset, from a product.  In that way, have a product focus.  I’m quite happy if people say I’m a product manager, I’m quite happy if people say I’m the product owner, or I’m a product leader, or a product champion.  I’m a business analyst.  

Gerry: You’re a human at the end of the day.  

Roman: At the end of the day, exactly, we’re all human beings, we’re all trying to create value for other human beings.  Hopefully, do other human beings some good.  That’s what it should be about.  

Gerry: That’s funny, myself and Adrian Tann did a talk a number of years ago about how product management and services design can co-exist.  The takeaway from it was, we boiled it down to what skills do we have and what do we need to get the job done?  Which is, at the end of the day, the old crafts and the guilds, you’re good at doing this, you’re good at doing that, we’re trying to create something here.  We’re trying to build something together, which is a nice Segway into the whole intersection of design and product.  I think before we get into that, it would be good for us to hear what your definition of a product manager is.  

Roman: My definition of a product manager is somebody who, similar to what I’ve already suggested.  

Gerry: The product owner, yes.  

Roman: Well, somebody who creates value for a distinct group of people, users, customers, and somebody who creates value for the business, or facilitates the value creation for users, customers, and the business.  Thereby, interact with other people from various business units and influences them and brings them together, and exercises a form of leadership.  That’s in a way my definition of what a product manager/product owner/product person should in a way be about.  

Gerry: Yes, so where have you seen product and design work really well?  Like, in terms of structures and outputs?  In terms of ownership of design, or ownership of product, talk to us a little bit more about that.  

Roman: My idea of how product and design fit together is, I feel product people should in a way provide the context and enable a self-organising team that ideally consists of designers and developers in other roles required to create a product that offers a great user experience and has the right quality.  Empower a group of those people, empower a team and provide that team with the right context to own a solution and run with the solution.  What I commonly see is, that product people spoon-feed detailed requirements on a continued basis to agile teams.  In a way, solution it too much.  In a way, dictate the solution and the details of the solution.

Whereas, I find it be more appropriate, it be more helpful if product people educated the team members about the users, about the market, about the domain, allowed some of the team members to gain direct access to the users.  Maybe take them along, carry out some user research together.  Give some of the team members the opportunity to listen to user feedback directly.  Then provide the context by offering an effective strategy and an actionable product roadmap, so that the team, the design/development team, the cross functional team can then, as I said, own the solution and then run with it.  

Empower those individuals and in a way set them free.  That is often some work, some additional work, an additional investment that product people have to do.  Then it frees you up to focus on other pieces of work to maybe do some more discovery work, do some more strategic work.  At the same time, I think it’s much more beneficial and it’s much more satisfying for the team members if they can really run with the product and really own the solution.  It’s a much more creative way of working.  

Gerry: Yes.  I think the product manager role seems like an enabler, so they’re bringing together the UX, they’re bringing together in some instances services design components, because you can have multiple product managers.  What does a good product manager look like in your sense then?  

Roman: I think one of the different elements that help product managers to be successful when it comes to skills, some are around being able to carry out tactical work.  Some are around being able to carry out strategic pieces of work around product strategy, product road mapping.  In addition to those hard skills, I think what’s really helpful is to develop some leadership and people skills, which in my mind is always related to self-development.  These are things like cultivating empathy and the ability to empathise with other people, users, customers, but equally, development team members and stakeholders.  

Reach out to others in a warm-hearted kind way.  Things like cultivating an open-mind.  Attentively listening to others practicing active or deep listening.  Taking the time and showing a real interest.  That not only helps discover underlying needs and interests and motives, but also, it builds rapport and creates trust.  

Gerry: That builds that mindset, as well.  

Roman: Yes.  It’s the foundation for collaboration.  You can’t collaborate if there’s no mutual respect and trust, at least some mutual respect and trust.  Otherwise, I think it’s impossible to work together effectively.  Then maybe also some more concrete skills around, say, decision-making.  How do you decide together with a group of people if you want to draw in stakeholders?  If you want to collaborate with the team, how can you make decisions together without resorting to design by committee and brokering a weak compromise.  Creating a product that’s a loose…

Gerry: A loose feature-set.  

Roman: Yes, thank you.  

Gerry: That’s okay, it’s all good.  

Roman: Related to that, dealing with conflict creatively.  Whenever people from different organisations with different perspectives engage, there’s likely to be some friction on conflict, it’s the most natural thing in the world, but how can we deal with conflict in a healthy way?  How can we maybe become a little bit more aware of the emotions that are present when somebody does something or says something that we don’t disagree with, or maybe work with an individual we don’t particularly like.  Those I think are very important soft skills that complement the hard skills.  

In a way, bring them to life.  Then allow product people to succeed.  I’ve been doing this exercise, and one of my courses, my product owner course, now for a number of years.  Where on the first day after lunch, I ask people to imagine that they’re doing an interview and they’re asked to hire new product people, new product owners.  I asked them, what would be the critical qualities, the critical traits that you’d be looking for?  Consistently, people come up with the soft skills that I’ve just mentioned.  

I think as a community, we tend to recognise that it’s those leadership skills, those people skills, those soft skills that are truly important for us to succeed, but funnily enough, there’s been very little emphasis on this type of skills development in product management.  We’re very much focused on hard skills.  We’re very much focused on tools, templates, and specific techniques, including myself.  

Gerry: It’s all about the methods in many senses.  

Roman: Yes.  

Gerry: Just going right back to some of the things that you said there around conflict and culture and setting that mindset up for your team, how does the product manager role work within the organisational culture context, when there’s multiple product managers?  I’m not answering your question here, but I am a little bit, Dr.  John Curran when I interviewed him ages ago, he’s now since joined with Ethno Pod on the show.  He spoke about the subcultures within an organisation, who is responsible for that if there’s toxicity in the team and there’s toxicity within your tribes, who’s responsible for fixing those things?  

Roman: Well, I think to a certain extent, it’s the job of everyone.  I think product people by definition are influencers.  As product people, we have an influence on others.  We connect with people from various business units and the team, the development team, in order to create and provide and offer, a product or a service for that matter.  By interacting with individuals, I think there’s an opportunity to be, in a way, a role model and behave in ways we’d like others to behave and act in a way that we think is helpful and is wholesome and skilful.  

It’s in a way ethical and conducive to collaborative work.  Now, if you have a team that is in a way held back by conflict and finds it difficult to really resolve the conflict, then certainly in an agile setting, there should be a qualified scrum master or agile coach who can help the team.  Similarly, if there are ongoing issues between the product person and the team, again, there should be an agile coach or scrum master who recognises that and brings that to people’s attention.  

Maybe can suggest ways forward.  Again, if I asked a product, you experience conflict with some of the stakeholders, then I think it’s important to recognise that and look into ways how you can address the conflict in a healthy and constructive manner.  There are certain unhealthy ways in how we engage in conflict.  It’s like being aggressive and confrontative and trying to win or being passive aggressive.  

Gerry: Speaking behind people’s backs’ and stuff.  

Roman: Possibly, yes.  Being in a way quite confrontative and trying to win or trying to back away from conflict, avoiding conflict or giving in and appeasing somebody who seems to be more powerful, more aggressive.  Just to minimize any losses.  That sort of conflict behaviour, which I find quite common, including when I look at how I personally deal with conflict, always operates from a win/lose perspective.  It always operates from the idea that somebody is right, and somebody is wrong and most likely, I’m right, and my intentions are good, but the other person’s intention most likely aren’t quite so good.  

I judge and I blame.  The blame is on you.  It’s your fault.  That is not a constructive way to deal with conflict.  Recognising that and recognising what is going on I think is the first step to deal with conflict more creatively.  In many ways, I feel that product people should be ideally placed to resolve conflict skilfully.  Ultimately, because I think it’s about becoming aware of our own emotions, what’s happening for us.  What is our story, what are our observations?  Then what emotions are present for us?  Equally, what’s happening for the other person?  

What are their observations?  What is their story?  What emotions are present for them?  Why are those emotions present?  What are the underlying needs and interests?  What are driving those emotions?  Being willing to, in a way, to do some research here.  I’m tempted to say user research, and listen with interest to the other person, even if it’s difficult, even if you dislike what the person is saying, or you dislike the individual full stop.  

Then understand, okay, how can we move things together?  What is a helpful request for me and what might help the other person?  I think too often, again, we’re focusing on positions, we’re staying at the surface, we’re focusing on who’s right, who’s wrong.  I think that way you can’t really resolve conflict constructively.  If you then try and negotiate a wee compromise, the conflict is likely to resurface sooner or later.  

I think it’s really about going deeper, about admitting that we’re human beings.  As human beings, we’re complex, sentient, well… beings.  We have emotions.  We have underlying needs.  Figuring out, what are those and how can we address them in a helpful way?  

Gerry: Absolutely.  All right, so, Roman, we’re coming towards the end of the conversation.  We always end the conversations with three questions.  The three questions from hell is what I used to call it, but they’re not so much hellish anymore.  The first question is, what is the one industry thing that you wish you were able to banish?  

Roman: Yes, certainly, when it comes to design, dark design patterns and making users in a way addicted to products, so encouraging addictive unhealthy user behaviour.  

Gerry: Yes, so ethical considerations.  

Roman: Yes, absolutely.  

Gerry: The second thing is, what is the one professional skill you wish you were better at?  

Roman: My personal skills.  My people skills.  

Gerry: Yes?  Well, they’re pretty good so far.  

Roman: Thank you.  

Gerry: Managing people on a day-to-day basis?  

Roman: Yes, managing people, managing myself.  I find conflict a very interesting topic.  There’s an old Beastie Boys song that says: You never know yourself that much at all until your back’s against the way, you never know yourself at all.  I feel that when we’re in situations where we’re uncomfortable, where we’re starting to get tense, that’s a great opportunity to self-reflect and ask, why is that?  What’s happening here.  

Gerry: Yes, I think that’s true for everyone.  

Roman: That’s true for everyone, yes.  

Gerry: The last question is, what advice would you give to emerging designer or product management talent for the future?  

Roman: That’s a very good question.  I find it hard to give a snappy concise answer to this.  For me, being a good product manager is really about being open to development.  I really like Carol Dweck’s mind around growth mindset.  In a way, keeping an open mind and having a can-do attitude in the sense that with the right effort and with reflected effort, we can all be good at a variety of skills.  I started to play the saxophone again after taking a break from it for over 20 years.  I find it fascinating researching or learning some facts about famous saxophonists, like Charlie Parker, for instance, who apparently practiced for up to 15 hours at times a day playing the saxophone.  

There’s a reason why he was that good, because he put in so much effort.  Now, I’m not encouraging anybody to excessively work or work super hard, I think it’s important to try and follow a sustainable pace and have a healthy way of working.  At the end of the day, if we’re not willing to put some effort in and reflect on what works well and what hasn’t worked well, then we can’t expect that our skills will improve.  That, to a certain extent, is part and parcel what I find of the growth mindset.  

I’m not saying that I can’t do it, but I can’t do it yet.  With the right practice and the right environment and with some patience and perseverance, then I’ll be able to do it.  I think that’s maybe my tip for young product or design professional.  

Gerry: Excellent.  Roman, thank you so much for your time.  

Roman: It was a pleasure.  Thank you.  

Gerry: There you have it.  Thanks for listening to Bringing Design Closer.  If you want to learn more about the other shows on the This is HCD Network, feel free to visit: thisishcd.com, where you can also sign up to our newsletter or join our Slack channel, where you can connect with other human-centred design practitioners around the world.  Thanks for listening and see you next time.  

End of Audio