Design Systems, Product management

Nine lessons from my first year as a design system product manager

No Comments

Twelve months ago I joined the BBC to work on the design system of one of the organisation’s key tech platforms, WebCore. 

WebCore powers the vast majority of web experiences including such as News, Sport, Bitesize etc.

Unlike other design systems that are versioned and installed, the WebCore Design System is built into WebCore and is viewed as the actualisation of the BBC’s Global Experience Language. In essence, this means that if you are building on WebCore, you have no choice but to use the design system.

This means 250+ individuals working across 20+ teams and, more importantly, the millions of users they serve rely on the WebCore Design System.

I’ve shared this information to provide a bit of context. 

From this point on, I will be talking more generally about design systems with the odd reference to what we’ve done as a team this year. 

1. Design systems are an essential part of modern development and design practices

If you work in a large organisation, the chances are you either have a design system in place or badly need one. 

Having product teams costs money. Having product teams repeatedly solve the same problems is a massive waste of money. 

Enter the design system. 

I like to think of a design system as a collection of LEGO blocks, with each block representing a problem that’s been already been solved by the organisation. The blocks are then available to other teams in the organisation who, as a result of not having to reinvent the wheel when deciding the design or code of a component such as a button or an accordion, can move faster or spend more time on innovation.

2.There’s huge potential for accessibility wins

If you are committed to accessibility (and you definitely should be), then you should view a design system as a powerful mechanism for change or improvement across an org.

If each component, as a pre-requisite for entering the design system, has been designed with accessibility in mind and rigorously scrutinised against the WCAG standards this will result in each team that uses that component benefitting from that initial a11y good practice.

The opposite of this can of course be true. That is why it’s essential for design systems to prioritise accessibility. Good work done at the point of entering the system can then act as a trojan horse, carrying good practice across the wider business.

There’s also a potential for design systems to prioritise a11y improvements that might otherwise never see the light of day. 

For example, our team spent a quarter ensuring our components, where possible went above the legal requirement and into WCAG’s enhanced AAA standard. We were able to roll these changes out globally in a single release which meant that each team that used these components, and the BBC audiences that interact with them instantly felt the benefits of these changes. I very much doubt these nice-to-have / above-and-beyond style changes would have made it to the top of so many team’s hectic backlogs and so, in reality, were only made possible through the existence of the design system.

3. Research is key

As the product person in a design system team, standard product principles apply. 

You’ll want to focus on improving performance and driving meaningful outcomes by solving the right problems.

However, the problems your design system faces are more than likely unique to your business or to the extent to which your design system is or isn’t being adopted by the wider business.

For that reason, we need to be conducting research, and plenty of it. 

Luckily for design system teams, our users are in the building. This means getting access to people, setting up your own user interviews and really getting under the skin of what is and isn’t working for your design system users is highly achievable. 

Embedding a culture of research into the team was one of my key priorities. 

The act of conducting extensive research has been hugely beneficial in a number of ways.

  1. It’s helped us to figure out where we should focus our efforts
  2. It’s brought us closer to our users, on many cases on first name terms. ie short feedback loops
  3. It’s in the process of helping us define a product strategy that will allow us to communicate to ourselves, our users and the wider business how we see our design system evolving in the coming 12-24 months.

4. People are your product too

Personally, I’ve not done product in a use case quite like design systems. 

By that I mean, you don’t really build a thing.

Yes, of course there are assets. You’ll likely have a Figma library, perhaps Storybook and some form of documentation site. And yeah, as a central team you may from time to time build or perform maintenance on some components. 

But what you’re actually building is a system, a culture, a way of working. And with that people aren’t just users of your product, they are your product. 

For that reason I’ve come to the conclusion that the people that use your design system are just as much a part of the product as the assets themselves. And if you aren’t successful in getting users to build into the system and make it part of their daily working life, you don’t actually have a design system. You just have assets.

If you just make it, they won’t come!

You have to make it easy as possible to use the product, crystal clear on the purported benefits, and you have to be prepared to listen, cajole, guide and encourage. Constantly.

This means that, in reality, design system teams are in the business of change and people management.  And this, by proxy, means that you’re in the business of communication, often across a sprawling org who’s employees (your users) have limited bandwidth or attention as they’re focusing on their priorities and not those of your design system.

How you manage this communication effectively is a whole post in itself. 

However, in a nutshell I believe you need…

  • Clear documentation around how to use the system
  • Obvious ways to access support when users don’t know what to do
  • Clarity around end-to-end governance processes
  • Mechanisms like guilds or council to help users discuss or share new components or work together on modifying existing ones
  • Ways to demonstrate the value of your design system both to potential users and to leadership.

5. Community matters

If people are your product, then that means you need to be able to rely on them.

There needs to be a sense of collective ambition and toil towards shared outcomes. 

You need to work hard to get people bought into an almost utopian all-for-one and one-for-all mindset in which we build with reuse in mind, putting the greater good ahead of our own selfish ends. You also need to be prepared to encourage people to help stand by their fellow worker’s support requests when they don’t understand why the component they built two years ago isn’t working as they expected.

How do you build community? There are a few things that come to mind. 

  • A clear purpose for the design system that folks can get behind. 
  • An ethos that encourages working in the open and taking other teams along with you on the journey. 
  • Forums for public dialogue, support requests and open ideation that are well attended and vibrant. 
  • The encouragement of evangelism.

WebCore’s community spirit is a key pull for its members. There are tonnes of knowledgeable individuals and teams that are willing to help out others building into the design system or taking something from it. There are open Slack channels that anyone can use to ask questions about how to use a component, seek help or knowledge or pitch a new idea. 

We also rely heavily on a fortnightly Community Call that acts as the design system’s townhall and, this year, have launched the concept of Design System Advocates – a group of evangelists from outside the design system team who, in exchange for advanced training and the opportunity to shape the future of the design system, invest time and effort in creating and encouraging best practice from  the wider community and suggesting and implementing plans to improve the design system and its processes.

Design systems are people-powered and people need community.

6. People love design systems. People hate design systems

Having not worked in the design system space before, I started off by researching as much as possible.

I quite quickly found there was a growing community of people working on design systems that were openly talking about their work online. 

This was great for me. Lots of people are incredibly passionate about this work and are trying to work in the open to spread good practice with others and help one another. There are great design system podcasts, training resources, online events, meet ups, Slack channels and books. I tried (and keep trying) to absorb as much info as possible. 

Not gonna lie, there was that much information it felt kinda overwhelming so I was super grateful to kind folks such as Ellis Capon, Scott Strubberg, Marianne Ashton-Booth, Robin Cannon, Steve Messer, Dan Donald, Grace Han and Amy Hupe who were kind enough to give me some of their time and wisdom. They all said variations on the same theme, this is a complex space, be patient and kind to yourself. 

So, that covers people loving design systems. But what about people hating them?

Well, as much as design system folk love the concept and can see the benefits, working in the design system world is still incredibly challenging because of the people / change side of things. These challenges may include convincing your org’s leadership that they should invest in having a design system in the first place, or trying to encourage colleagues that building into a design system may take initial effort but that will lead to greater efficiencies in the long run or trying to encourage those already using a design system to stick to agreed best practice. Sometimes working in spaces like this, where you can see the benefits but your job is to constantly convince or course correct others can, to be honest, feel draining and repetitive. It definitely takes a certain type of person with a high degree of resilience. 

I think this is why the wider design system community is so vocal, active and supportive of one another. It certainly does help too.

7. Demonstrate value and celebrate wins

This aspect of design system work, the constant convincing and seeking of buy-in has can frequently contribute towards both team and individual burnout. 

Plus, design system work frequently relies on cross-team collaboration, often across a big organisation which, as you can imagine, can lead to the work feeling slower than if you were just building products and features. 

What I’m getting at is, sometimes design system work can feel a little thankless, if you let it.

At a point in which I was feeling particularly deflated, I saw Amy Hupe give a talk at the wonderful Converge Festival on the importance celebrating your wins.

I found the talk inspiring and since then have tried to create a culture that celebrates our successes as a team both internally and externally. 

So, what does this look like in practice?

Whenever we complete a significant piece of work, or help other teams unlock value via the design system, you can bet on us hitting up the company Slack channels or putting a blog post together. Often times, the design system lets other teams build new experiences faster than they would have been able to without it. When new releases happen within the company, we try to speak to the team and find out how much they relied on the design system or collaborated with other teams and create content around this to both promote the value of the design system and encourage more similar behaviour in others. Doing so helps to show others in the company the value of design system and goes a long way towards encouraging wider buy-in. 

However, what is equally important is celebrating our wins within the team. The team I’m in is full of some of the brightest, most committed and intelligent people I’ve had the pleasure to work with. Giving kudos to one another and calling out and celebrating what we’ve achieved both individually and collectively really helps. It is necessary to pep one another up to maintain the required reserves of motivation, morale and energy often needed to work effectively in design system world.

8. Governance? Yes, please

A lot of the job is making it easy for others to use the system. 

This often means governance is required. 

For example, a team is just about to create a new user experience. They aren’t sure whether they should use a component that’s already in the design system as it gets them 90% of the way there or create something from scratch. 

How do they make that decision? Who do they need to talk to? And, if they decide they want to use what’s there but slightly tweak or amend it, how do they go about communicating the purpose and need for their proposed change to the wider community?

Its ironic, design systems exist to bring about efficiency by reducing the need to resolve problems. But, without clearly defined and communicated governance processes, you’re asking users to reinvent the wheel each time they want to figure out how to achieve something using the design system. 

Recently we’ve spent a lot of time and energy improving and clarifying our governance processes and, although communicating them and encouraging wider adoption will be a long game, we’re certainly seeing early successes. What’s more, users are telling us they’re grateful for us doing this work, a lot of which has been done with input from the whole community, especially the Design System Advocates.

This was interesting as we had a lot of conversations about not wanting to be the design system police. However, what we actually found when digging into this is that people working on a design system want and need governance to make it easier for them to work. Rather than feeling like we’re bossing people about, they’ve told us our role is to make it clearer what the rules are and how best to proceed. 

Rather than the design system police, we’ve taken to viewing ourselves as the gardeners of the design system, our role is to create a harmonious space through pruning and growing, and, by doing some occasional weeding too when stuff you might want tries to find its way into the design system.

9. Metrics ftw

The design system space is quite famous for not being great at telling a compelling story through numbers.

This is a shame, as we’ve discussed not resolving the same problems multiple times = baked in efficiencies and savings for the org.

Therefore, I feel the design system world needs to get better at demonstrating the ROI of having a design system.

One of our early stabs at trying to show the design system’s value was to analyse the role it played in launching the BBC’s For You experience.

We discovered the team behind the page, a key pillar in the organisation’s personalisation strategy, was able to create take the experience from concept to market in a matter of weeks owing to the ability to pick up high-quality and reusable components that already existed in the design system. 

We gave a huge amount of kudos to the team for following great practice in terms of trying to build new experiences by using what already exists in the design system. That team, having got something out to users quickly, are now looking to iterate and improve the experience and are likely to create new, innovative features and components that don’t exist right now in the design system and therefore, when created, will provide value to all the other teams that can them have access to them too. 

We were delighted to be able to tell this story, but our goal in the near future is to be able to tell stories such as this without as much manual investigation and with hard numbers attached.

We’re working on getting automated access to a number of metrics we can use to measure and improve the performance of the design system, tell better stories and make data-driven decisions.

These include knowing things such as speed-to-market, speed-to-prototype, components used by the most/least amount of other teams, components seen by the most / least amount of audiences.

We’re excited to eventually get access to this data in order to better demonstrate the value our design system provides to the organisation and encouraging wider and deeper cultural buy-in.

Thanks for reading

If you’ve found this article helpful, why not sign up to the newsletter, or subscribe to Product Confidential, a product management podcast I co-host with Evie Brockwell.

Continue Reading

Careers, Product management

Career change – how do I break into product management?

No Comments

My journey into product

In 2019, I was fed up.

I’d been in marketing for about seven years and was not enjoying it anymore.

I’d learnt some great transferable skills but I just didn’t feel inspired by writing copy, creating adverts, monitoring engagement etc.

Instead, I wanted to be a part of a team that was building cool stuff and solving problems.

Without realising it, I’d always been trying to do product management by way of changing the website to better hit business goals (usually lead generation) and user needs (information, events, content).

Around this time I first heard about product management and it sounded like the exact thing I was looking for. I was fortunate enough to land my first role in product in 2020 and, four years’ later, feel settled in the profession. It’s been a good for me – I’m fortunate enough to say I enjoy going to work each day.

When I was trying to transition from marketing to product lots of people, in what I now know to be a deeply collaborative and helpful product community, were generous with their time; giving me a tonne of useful advice, guidance and encouragement.

Trying to give back

I’m now in a position in which people, looking to embark on a similar career journey that I went on, message me on LinkedIn looking for advice. Remembering how helpful people were to me when I was, I always make a point of trying to give back.

My recommendations for getting into product

So, what advice do I give to those people?

Get Connected

As mentioned earlier, the product community is awesome.

Since joining it, I really feel like I’ve found my tribe.

They tend to be people that enjoy their craft, are eager to learn new things, have no qualms sharing expertise and help and like to lift each other up.

Tap into that. Mind the Product run monthly ProductTank meet ups in pretty much every major city. Tap into that. Go an listen to what I can almost guarantee will be amazing talks but more importantly, meet some people and be open about your plans. I’m sure, along the way, someone will let you know about a job or introduce you to someone hiring.

Likewise, don’t be scared to add people on LinkedIn and ask for advice. It might seem scary but in my experience most people are glad to help as they remember others taking the time to help them in the past.

Look for associate roles

An associate product manager is like a trainee / apprentice product manager. Companies looking for people with good skills but no product experience will often hire an associate with a view to pairing them with senior product people so they can learn their craft. This was my route in and I couldn’t recommend it enough.

Consider an internal transfer

If the associate route doesn’t work for you, or you can’t find one, can you find a company that has a product function that you could, once you worked there, transition into? It’s a bit of a long game but I’ve heard of lots of people that retrain within their existing company into the product position.

Learn, learn learn

There are awesome resources available for aspiring product managers.

Mind the Product’s website is full of tonnes of free resources.

There are brilliant online courses where you learn the basics and get accredited.

There are great newsletters such as Product Breaks.

There are awesome podcasts out there. My personal faves include Lenny’s Podcast, The Product Experience, Product Thinking with Melissa Perri.

Some of the books I found most helpful for understanding the role of product management include Marty Cagan’s Inspired, Teresa Torres’ Continuous Discovery Habits, Matt LeMay’s Product Management in Practice, and Eric Reis’ The Lean Start Up.

I try to keep learning by co-hosting the Product Confidential Podcast with Evie Brockwell. We’ve recorded some episodes that I think give great advice to people at the start of their product journey which I’ll call out below

Adil Hussain on the associate product manager role

Susana Lopes on advice for people in their first product role

Don’t be intimidated

Doing recommendations 1-4 will give you a good grounding in the fundamentals in product and go along way to demonstrate your passion and determination for your planed career change.

Following these steps won’t make you an expert. And that’s okay. That will come with time in the role, good management or coaching, and putting theory into practice, but that’s not the problem you’re trying to solve right now.

When learning, try not to make the mistake I made of thinking that product is some kind of scary science that you will never be able to master. To be honest, a lot of it comes down to common sense, pragmatism and being nice to people.

If you are looking for a role in product, I hope this post has been helpful.

Good luck, and do feel free to reach out to say hi. I’d be glad to hear from you.

Continue Reading

Careers, Product management, Start-ups

Transitioning From Large Organisations to a Scale-up: Insights from Product Leader, Adam Warburton

No Comments

Evie and I recently had the pleasure of speaking with Adam Warburton, a seasoned figure in the product world. Currently serving as the chief product officer at Vypr, Adam’s wealth of experience spans larger corporations, like Co-op, down to being a product trainer and organiser at ProductTank Manchester. Adam shared his perspective on transitioning from large organisations to a scale-up and the differences in product culture, providing valuable insights that can shape the trajectory of numerous professionals’ careers.

## Bridging the Gap

Adam’s fascinating transition from a large organisation to a scale-up, lent to intriguing insights about the dynamics of both scenarios. While many may romanticise the idea of working in a startup due to its dynamic nature, Adam clarifies that there are inherent challenges to consider. He explained that different roles come with their own unique set of challenges, and one must choose where they fit best.

In larger companies, the challenges lie in complex stakeholder management and the need to explain and uphold certain procedures and frameworks. The dynamics of startups, however, require a completely different skill set, emphasising concerns such as financial reality and the need for a high-performing, compact, and adaptable team.

## The Power of Flexibility and A Bias for Action in a Scale-up

Adam noted that his journey in a scale-up required a new approach, shedding formalities and relying more on quick, agile decisions. With the fast-paced nature of startups, frameworks that are deemed necessary in large organisations tend to be less rigidly implemented. Instead, companies place more value on achieving alignment on what is crucial and necessary for growth and success, which expedites work-efficiency. 

The need for swift, impactful actions necessitates a shift away from traditional work patterns. In smaller organisations, the complexity lies in delivering powerful products with limited resources, which requires flexibility to address and adapt to constantly changing situations. 

Notably, having a bias for action and being impact-obsessed sets the groundwork for a winning team. This does not imply excessive working hours but rather ensuring tasks are done productively – a recipe for work-life balance in a startup.

## The Influence of Leadership in a startup 

Nonetheless, Adam’s experience does not idealise working in a scale-up without acknowledging its potential drawbacks. The fast-paced environment can be intimidating for those who are more accustomed to methodical and slow-paced work patterns. Adam advises potential candidates to observe the behavior and ethics of the leadership of the startup they’re considering, as these are significant indicators of the work culture.

In summary, whether one thrives in a large organisation or in a scale-up ultimately boils down to adaptability, resilience, and the willingness to unlearn and relearn. One of the key takeaways from our conversation with Adam is that the measure of success isn’t necessarily based on conforming to a specific framework or practice but on the individual’s ability to understand, integrate and balance the demands of both efficiency and adaptability.

Listen to the show, here
Watch, here
Continue Reading

Careers, Product management

The truth about product management in big tech – insights from an ex-Googler

No Comments

In our globalised world, we perceive Big Tech companies like Google, Meta, Amazon, and others as the ideal places to work.

Their aura of innovation, high technology, and competitive compensation attract professionals from all walks of life, especially those looking to establish or accelerate a career in product management. However, as promising as they seem, working at these tech giants isn’t always a walk in the park. 

In the latest episode of Product Confidential, Evie and I were joined by a special guest, Alex Rechevskiy, a former Google Group PM, and now coach to hundreds of PMs that want to get into Big Tech.

Alex, a product management veteran, lifts the veil on what it’s actually like to work at Big Tech companies. If you want to watch or listen to the episode, scroll to the bottom of this page or if you’d prefer read this breakdown of their tips for effective and sustainable career growth within big tech product management.

Behind the High-Tech Curtain

Many, if not all, aspiring product managers dream of landing a role at Google, Meta, or any top-tier tech company. These organisations are heralded as the penultimate goal, the embodiment of success in the field. But, like any organization, they have their ups and downs. Being aware of both can help in making an informed decision. 

At these companies, the potential for vast impact exists due to their global reach and resources. Also, working in such organisations opens the door to better compensation and career prospects. However, the opposite side of the coin reveals a slow and often bureaucratic decision-making process, potentially soul-crushing workloads, and a severe focus on quarterly metrics which can hinder creativity and long-term innovation. 

Shattering Hopes or Setting Realistic Expectations?

Although we’ve highlighted some of the challenges of working in Big Tech, we aren’t suggesting these companies are undesirable workplaces. Instead, we aim to set realistic expectations to avoid disillusionment and disappointment in the long run. 

The factors that make these organisations great places to work are real. They offer unparalleled learning experiences, significant career trajectory opportunities, robust compensation packages, and access to a network of brilliant, like-minded professionals. But, it is also important to remember that they’re large corporations, and the realities of corporate life apply to them as well.

Tips for Product Career Growth

Despite the challenges, a stint in a Big Tech company can turbo boost your product management career. If you’re considering that path, here are some tips to help you:

1. Understand the Interview Process: Each company has its unique interview structure. Familiarise yourself with the process, identify company-specific principles, and prepare accordingly. 

2. Time Management: Give yourself ample time to prepare for interviews. A three to six months preparation period is ideal as it gives you enough time to grasp the company’s principles, practice your interviewing skills, and get feedback from professionals in the field.

3. Be a Self-Starter: Success in these companies requires proactiveness and relentless pursuit of your goals. Take charge of your learning, identify your objectives, and stick to them.

4. Build Relationships: Foster positive relationships across the board. Seek mentors within the organisation and learn from their experiences.

5. Clarify Your Goals: Understand exactly why you want to work at these companies. Align your aspirations with your chosen company’s vision and make sure you have clear reasons. 

No matter where your product management career takes you, whether that’s Google, a mid-sized enterprise, or your own start-up, keep sight of why you chose this path. Work-life balance and personal satisfaction should be the baseline of your professional goals, wherever you may be in your journey. Remember to keep growing, enjoy the process, and celebrate each win along the way.

Listen to the episode here
Continue Reading

Product management

First month in a new product role!

No Comments

Four weeks ago I started a new role as a Senior Product Manager at the BBC.

I really loved working at the Department for Education (DfE) and have a debt of gratitude to the organisation for creating the associate pm role that got me into product in the first place.

But I must say, I’m so made up to be at the BBC.

The entrance to New Broadcasting House

The BBC fascinates me. I love it and I always have. Like most living in the UK, it’s been an ever constant in my daily life and I’m pretty certain it’s the brand that I’ve trusted the most and spent the most time interacting with.

So to be a part of it, as a senior product manager, in less than three years since I got into product management really is a dream come true for me.

Getting to change roles has allowed me the opportunity to further develop my craft in a different setting to DfE. Will product management be the same in the BBC as it was in government, will I be able to do it? Will I enjoy it as much? All this remains to be seen, but I’m very much looking forward to the journey.

The first thing the role change has encouraged me to navigate is, how do you go about starting a product role within a different organisation? A new challenge for me. I’ve changed roles before but within the safety and familiarity of DfE.

In this article, I’m just going to blog about what I did and what I didn’t do as I started this new role within the BBC’s Design System team more as a chance to reflect. I’m not positioning this as a ‘here’s what you should do to successfully join a new org’, more just sharing what I did in the hope that some of what I say might be helpful for anyone else out there preparing for a brand new PM job.

The view from the top floor of New Broadcasting House

Recharge the batteries

Firstly, I wanted to make sure I didn’t turn up feeling like I was running on fumes. Between January and February I had been working pretty much flat out at the DfE and could feel I was in need of a break. Luckily, I had 8 days holiday to take before my start date in May and that coincided with King Charles Bank Holiday Bonanzas so I had quite a lot of leave in my final month plus some time between my last day at DfE and start date at the BBC.

I was really grateful for that and felt refreshed and ready to start a new and exciting challenge.

Pre-start prepwork

I may have got the job but what even is a Design System though?

I’d swotted up enough to get through the interview but soon I’d be in the weeds with people that had been working on this for a long time.

Obviously, it’s okay to not be a subject matter expert when you join a new space.

In fact, I think not having a great deal of knowledge on the subject matter can be beneficial to product managers as it encourages you to go full Columbo asking question after question as you build up your understanding (sometimes unearthing things that other people don’t know too).

When I started digging into the Design System space, I found a buzzing community with lots of hugely passionate people. I started periodically checking out loads of blogs, podcasts and books and making a list of thought leaders in the space.

Every now and then I’d email someone that I’d been listening to / reading and ask if they could spare any time to help me build my understanding.

Although being so forward might feel a bit uncomfortable to begin with, my takeaway is that, overall, people are nice and want to help.

I was really blown away with how generous people were with their time and those conversations with either other PMs in the space or general Design System practitioners really helped me to build my confidence and feel like I had a bit of a headstart on getting a feel for the area.

I also feel like I’ve made some allies in the Design System world who I can turn to for objective advice, and hopefully, when I get more up to speed, start helping them with some of their problems/projects too.

Meet the team early

I totally get this isn’t doable in most cases but I was really fortunate in getting to meet people in my team early. I had a long notice period and some of my new team were kind enough to reach out on LinkedIn to say they were excited for me to join. I was made up with that alone but then they took it a step further and asked if I’d like to come into the office and have a coffee and a catch up with some of them.

That was such a lovely experience. They gave me a tour of the BBC (very exciting) and then we spent an hour just getting to know one another. Everyone was so nice and it just really relaxed me, put me at ease and just feeling mega excited to get started and work with such a thoughtful bunch of people.

Actually getting started

After getting set up on systems and sorting my laptop out, the thing I was most keen to do, and what I’d set as my objective for the first two weeks, was to meet as many people as possible.

My line manager had been kind enough to make me a list of suggested people, so using that list of names, plus each member of my team, I went about putting in 30-mins informal coffee catchups with people.

Where possible, I put these meetings in face-to-face. Reason being, there main objective was to get to know people and for them to get to know me. Wonderful things can be achieved via remote working, but personally I feel I connect with people better IRL.

To give these catch ups a bit of structure, in between chatting about everything and nothing, I’d ask three questions to each member of my team.

  1. What are this team’s superpowers?
  2. What things could this team improve upon/ what are it’s key challenges?
  3. What would you like to see me, as product manager, do to help the team?

For those not on my team I didn’t ask the above questions, but instead focussed on finding out about their role and where our roles / teams would interact or overlap. I also asked everyone for their opinions on how we could and should work well together.

I found this period both thrilling and exhausting.

Meeting new colleagues (and hopefully friends) for the first time is really cool.

However, meeting lots of new people, mainly via Zoom, in such a short space of time is also quite mentally tiring – but I wouldn’t change a thing.

I can’t overstate how much emphasis I think should be placed on meeting as many people as you can early on, getting their sense of what’s important, and most importantly – showing people that you’re interested in the work and interested in them. A huge proportion of doing this job effectively relies on personal relationships and you don’t get a second chance to make a first impression.

Start a murder wall

Now as well as a list of people to contact, my line manager also sent me a load of documentation to read through. The documentation was really in depth and useful but on a personal level I find I learn much more from doing or through conversations than I do from reading documents. However, I did read everything I was sent.

As I went through the documents, I also had a Miro board set up as my murder wall.

But what’s a murder wall, I hear you ask? Well, you know on police shows were they take up a whole wall and visually map all the clues, evidence and suspects? It’s basically that but instead of solving a crime you’re trying to piece together the new team / project or problem you’re solving.

As I went through the documentation I used the Miro board to link to all the docs I found useful / interesting and, most importantly, I also collected a load of questions I had about what I’d been reading.

Other things that went on the Miro board included questions I had about how the team operates. For example, one post it note read ‘what are all the ways in which work enters the team?’ I’d also use the board to note down any ideas I had.

At first I had little structure, just dropping down ideas, thoughts or questions as I had them on the board. Structuring these abstract ideas actually helped me come up with a plan of action, which I’ll come to a little later in the blog.

Slow down, don’t be hasty

One thing I think it key is making the most of being new.

No one is expecting you to lead on things, know everything or to be making important decisions as, quite frankly, it would be weird for you to be doing so with so little knowledge of the space.

That being said, there are times when the temptation is there.

You might see a problem you’ve encountered in an old team and know a process that worked there, or have some ideas on what you think backlog refinement should look like. However, I strongly recommend holding off sharing your ideas, or trying to get them implemented too soon.

There are a few reasons for this.

  • Keep using this period to meet people and to sponge up new information. If you get into the ‘doing’ it’ll eat into your time in which it is acceptably to just focus on learning – you won’t get this time again so try to get as much value as possible
  • There might be good reasons why the team don’t do the thing you think would revolutionise team processes – so take time to find out as much as you can about the context of how they arrived at current ways of working before jumping in
  • You haven’t built up trust yet and nobody cares about how your old team did things. I think this point is huge. If you come in like a bull in a China shop – ripping up processes – then the chances are you’re going to put people’s backs up.
  • Instead, take the time to slowly build up trust, take on small projects and show you’re adding value. Hopefully then, if you’ve proven you’ve got best intentions and have progressed some things you’ve been involved with, the team will be more open to new ideas.

Start making a plan

Between the documentation, going to meetings, meeting my team and building out my network – plus all the thoughts on my murder wall, I’d started to collect a lot of information and ideas.

After three weeks, the time felt right to start to start leaning more into the doing rather than the learning.

I decided my first port of call would be to theme and group all the questions / ideas on the murder wall.

Quite unexpectedly,  what emerged were six quite distinct areas that, when scrutinised, felt like they were either problems to solve, possible processes to introduce or potential opportunities to add value.

From these I formed a small plan of where I think we can improve or introduce new ways of working.

Start communicating as soon as possible

Now, I might have thought the areas I’d outlined seemed like good things for us to be looking at as a team. But did everyone else?

Where there other initiatives they thought were more pressing, was there a reason one of the areas of focus I’d suggested wouldn’t work, or alternatively, would the team be excited about the things in the plan?

Well, there’s only one way to find out…share where you’re at and what you’re thinking and ask for feedback.

So that’s what I did. I created a quick and dirty slide deck in which I…

  1. Explained that I was giving this update as I believe in working in the open, overcommunicating and eliciting feedback early.
  2. I played back the overlapping themes that came out of my informal 121s on what the team was good at, where there was room to improve and what people wanted a PM to be doing in this space
  3. I then went over the murder wall, the questions I had, and then shared the six areas of focus that emerged.
  4. I then shared what my short-term priorities looked like i.e. the things I’d be doing in the next 6-8 weeks. I followed that by sharing more longer-term ambitions for both myself and the team, things to look to achieve over the next twelve months or so.
  5. Then, and most importantly, I asked for feedback. This led to some really useful conversations in which the team challenged some of what I said adding the fresh perspectives I’d sought, but also showed excitement regarding some of the opportunities I’d shared.                                                                                                                                                                                                                                                                                                                                                                                                         

Move from learning to doing           

I’d been really pleased with how the session went. I felt the conversation well and I hoped by playing back what I’d learnt from the 121s I’d shown I’d been actively listening. And also that I’d been taking on people’s opinions and using them to shape a plan. One that I didn’t launch into too early, and one in which I’d returned to them for feedback before putting it into action.

With the team seemingly bought into the short and long-term priorities I’d shared, I now felt like I had a mandate for action and a plan of attack I could refer back to as I came out of my observation phase and ventured into the realm of actively doing.

I’ve really enjoyed being new, meeting people and learning as much as possible and everyone has been super welcoming, which always makes things easier.

But now I feel ready and excited to start putting some of the ideas to practice and hoping they result in improvements for both the team, our users and the business.

I’ll keep you posted on whether that’s the case as the weeks turn to months – so sign up to the newsletter if you’d like to hear more.

Continue Reading

MVP, Product management

Define your MVP with User Story Mapping

No Comments
User story mapping

My lovely team taking part in a user story mapping session – the main focus of this piece.

In my previous article I discussed what an MVP looks like in government and that, whilst they are not a true MVPs, defining one is still an essential requirement to moving your team in the right direction.

In this article I aim to get amongst the weeds and discuss how you actually go about defining your MVP.

The article will focus on a technique called user story mapping and briefly touch on how you can use visualisation techniques to help bring your stakeholders on the journey.

Some important prerequisites

Before you can effectively use user story mapping, it’s advisable that you have done the following things.

  • Ran a discovery to understand the problem space and the user needs that you are trying to solve.
  • Created an as-is service blueprint that shows the current process users must navigate, making it easier to visualise where your product can add value.
  • Go through an alpha stage to devise and test some concepts that you may use to meet user needs.
  • Agree upon the winning concept that you can develop into the MVP you plan to release in order to test and learn from.

Before we get into user story mapping, I just want to clarify something.

If you’ve agreed upon the winning concept in the alpha stage, why do you still need to define the MVP?

Well, in my experience, even when the concept has been agreed upon, there likely to still be debate within the team over how to best implement it, or around which features are truly necessary for the first release as opposed to being nice-to-haves that can come later.

Here’s where a user story mapping session is really useful and can help your team nail down what’s going to be included within the MVP by teasing out some interesting conversations.

User story mapping

User Story Mapping is a technique associated with Jeff Paton and is, in his own words ‘a simple idea’.

One that I’ve found to be unparalleled system in helping teams showcase the entirety of their product, build shared understanding and simplify complexity.

What is user story mapping?

It’s a process that will help your team to visualise your product’s features in it’s entirety, including features you want to launch with, plus what to expect from later releases.

How do you run a user story mapping session?

I prefer to do user story mapping in a room using post-is but you could just as easily use a digital whiteboard. Try to make it a collaborative session in which attendees agree upon what user stories are needed to help meet the needs that have been identified in your discovery, and the order in which they’ll be met within your product.

On the board you’ll have your top-level row running from left to right that will have your high-level tasks, or epics.

Underneath that you can have the tasks a user will need to take to complete your epic.

And finally, underneath place the features (or user stories) that are required to enable the user to complete the tasks.

The task will be for you and your team to firstly agree the epics, and then work your way down the board row by row, agreeing what user tasks and stories are needed to complete each epic. What you’ll be left with is a top down view of your whole product from the perspective of your user.

Top tip for running the session.

Have an icebox section in which you pop ideas for the future or questions you may need to answer or consider. Reason being, as you go through this process you may find it triggers some amazing thoughts and discussions within your team. And whilst that’s all well and good, it is handy to have a way to put a pin in discussions that are going too far off track whilst also making a note so you don’t lose cool ideas that may come in useful down the line.

Below is an example of the end result of a user story mapping session.

Example of user story map. Image from http://winnipegagilist.blogspot.com/2012/03/how-to-create-user-story-map.html

What does story mapping help you to do?

  • Walk through the whole user journey and see the bigger picture.
  • Visualise the MVP and help the team build a shared understanding.
  • Unearth fantastic conversations about the product that may not otherwise have surfaced, especially around prioritisation.
  • Prioritise what features are required for MVP whilst also defining your future roadmap of releases.
  • Define how your solution will meet the needs identified in discovery / alpha phases
  • Understanding dependencies and showing where you may have blackspots or unknowns in your user journey.

Visualising the MVP

Whilst the user story map that you’re left with is a helpful exercise to go through and will leave you with an asset that your team will understand, I personally feel the end result is perhaps a little off putting to stakeholders.

That’s why, I recommend supplementing this work with low fidelity hand drawn wireframes that you can use with stakeholders to bring to life what you and the team have in mind in an accessible fashion.

Image from https://miro.com/templates/low-fidelity-wireframes/

Did you find this article useful?

If so, I urge you to do a number of things (should you wish to)

  1. Sign up to the newsletter and receive new posts straight to your inbox
  2. Follow me on LinkedIn or Twitter
  3. Share the love and post this article on your social media accounts
Continue Reading

Government Delivery, MVP, Product management

MVPs in Government Delivery: Part One – are they actually MVPs, and if not, do I need one?

No Comments
Grey building blocks

What is the concept of an MVP?

When I was trying to break into product management, I spent a lot of time reading about agile. My favorite book on this topic is the seminal “The Lean Startup” by Eric Ries.

If you are looking for a book that brings the principles of agile to life, look no further. One of the key things I took from that book is the importance of creating a minimal viable product (MVP) – something Ries defines as a version of a new product that allows the team to collect the maximum amount of validated learning about customers with the least amount of effort. A key concept of “The Lean Startup” is the build-measure-learn feedback loop.

The idea is to eliminate uncertainty by putting products or even concepts out into the wild as early as possible to see whether they have legs, whether the ideas can be improved, whether you should pivot to a new course of action or simply abandon the idea before you waste time and money on something people aren’t interested in. The first step in this process is to establish a problem that you think warrants solving. The next step would then be to define a solution (or an MVP) that you think will help you to solve the user pain point. You would then aim to release this MVP as early as possible to test it with users and iterate based on your findings of live use cases.

Examples of successful MVPs

The origins of the company Zappos are a well-known example of a successful MVP. Nick Swinmurn, Zappos’ founder, wanted to know whether people would buy shoes online. Before buying a load of stock, he tested the concept by creating a website with a load of pictures of shoes that people could buy. If they bought them, then he would go to a shop, purchase them, and post them out himself.

This was a low effort, low-cost way of discovering that people were, in fact, happy to buy shoes online, and so, with that, his business idea took flight as he fine-tuned the MVP into the company that we know today. Check out this link for more examples of successful MVP case studies.

What does the MVP process look like in government?

In my experience, I’ve found working in the public sector prohibits MVPs in their truest sense. It always seems like there is a reticence against putting something truly minimal out there.

I think there are a few factors in this: the civil service having a low appetite for risk, ministers expecting to see something quite polished, and the miles of bureaucracy, red tape, and governance steps you need to navigate in government before you can release anything onto the internet.

This means that government projects tend to use alpha phases to test concepts using prototypes and user research as opposed to observing behavior on live software. Therefore, when government projects launch what they refer to as their MVP into a private beta, what is being released tends to be more like a small-scale version of the eventual product, backed up by a roadmap of future features, as opposed to a true MVP as defined by Eric Ries. Note – for the rest of this article, when I refer to MVP, I will be talking about the civil service-style MVP as outlined above.

Why is it important to define the MVP?

I’ve found that if a team hasn’t defined the MVP at the point in which they are close to starting the build, trouble lies ahead. Not defining the MVP means that everything is still possible, no parameters have been set, and everything is still on the table. Therefore, team discussions are often too broad, theoretical, and likely to bolt off in a multitude of disparate and confusing tangents.

There are a lot of unwanted repercussions from the above happening too. Meetings feel bloated and do not result in outcomes. It is hard to arrive at decisions, and the team will complain they are unsure of the direction. Morale and progress are unlikely to be where you want them to be. Additionally, teams will not be enjoying what I have come to consider to be vital aspects of successful digital delivery – shared understanding of the problem space and a consensus on how to solve it.

Tune in next week for more…

So, hopefully, this article has helped you understand:

• What an MVP is

• What one looks like in government delivery

• The pitfalls of not having one defined

The next article in this series will take a look at how to define an MVP, ways to visualize it, and what to do with it now that you have one.

If this sounds good to you, be sure to sign up for the newsletter to receive it straight to your inbox.

Continue Reading

Product management, Relationships

Product managers and delivery managers: two sides of the same coin…sometimes!

No Comments
Two jigsaw pieces fitting together

Football has delivered many fantastic partnerships – Shearer and Sheringham, Yorke and Cole, Rush and Dalglish.

Within these dream pairings, it often seems like the two protagonists have an almost telepathic understanding – that they know instinctively what the other wants and needs, and so can combine in a way that is devastating for the opposition.

Well, this is what product managers and delivery managers should be aiming for in their working relationship.

Maybe not to devastate the opposition, but to gain a level of understanding that leads to optimal performance for them and the wider team. This article will touch on the differences between the roles, establish why the PM/DM relationship is so important, and offer tips on how to make the relationship work.

What are the differences between product managers and delivery managers?

A lot has been written in this space, for more detail on this, check out this article.

For the purposes of this article, I find the following definition the most simplistic and accurate – the product manager is focused on the ‘what’, and the delivery manager is focused on the ‘how’.

So, the product manager is responsible for defining the product, the vision, the strategy, and the roadmap, as well as prioritising and maintaining the backlog.

Meanwhile, the DM is accountable for ensuring the team can achieve what’s been set out by monitoring team health, capacity, velocity, and team access to tooling while defining delivery plans and mitigating any risks or blockers the team or product faces.

There are also some overlapping areas such as stakeholder management, agreeing team processes, and providing the team with a fun and safe working environment in which to thrive.

Why is the product/delivery relationship so important?

As you can see, a lot of responsibility falls on the shoulders of the product and delivery manager, and it is quite easy to see that if the two aren’t well-aligned, then it’s likely to spell disaster for the rest of the team.

That’s why, as a product manager, I firmly believe that my most important relationship within a multi-disciplinary team is with my delivery manager, and so I focus a lot of time and energy investing in this vital relationship.

When this relationship is working, the product manager and delivery manager can combine effectively and begin to operate as two sides of the same coin. Both parties have shared goals, priorities, and desired outcomes, yet they both tackle the shared problem space from different perspectives, have different responsibilities and rely on different skill sets from one another.

What does good look like?

Firstly, the relationship between the two must be a partnership – one built on trust, common understanding, and shared desires.

To get to that point, the two must have spent time investing in the relationship, to have clear and understood lines of responsibility, to know each other’s strengths and weaknesses, and to know how to respond to each other when things aren’t going well, or there is conflict or misalignment.

When firing on all cylinders, the PM/DM can combine to become a real force to be reckoned with.

A duo that, between them, can inspire, support, and cajole teams into hitting their objectives and building products that exceed desired outcomes from users and the business. 

Alternatively, if the relationship is struggling and the two parties are not aligned, you can expect to see a misfiring team that works inefficiently, has poor processes, complains of a lack of direction, feels demotivated, and has little chance of delivering value.

How can you improve the relationship with your delivery manager?

Achieving this kind of understanding is not easy, and like most good things, it will take time and dedication to develop.

However, there are some things you can do to help get the PM/DM relationship off on the right foot or reinvigorate one that needs a bit of TLC.

One fabulous delivery manager I worked with recommended that we start our relationship with a contracting exercise. It worked so well that I now do it with every DM I work with, and it has been a massive help in forging strong relationships (and often friendships, too).

In the section below, I will explain how to run that contracting exercise and provide some examples of the kind of things that have come up when I’ve taken part in it.

The exercise itself is straightforward but will go a long way in helping you both understand one another, agree on expectations and ways of working, and provide an opportunity to check back in and review how the relationship is functioning at regular intervals.

How to run the contracting exercise

Either in person or using a remote whiteboard or shared document, both parties spend 15 minutes in silence writing answers on post-it notes to the following eight questions.

  1. What does [Insert PM’s name] expect from [Insert DM’s name]?
  2. What does [Insert DM’s name] expect from [Insert PM’s name]?
  3. What would make working together awesome?
  4. How will we deal when conflict or challenges arise?
  5. How do you like to receive feedback?
  6. What are your strengths?
  7. What are the areas you’d like to develop?
  8. How can we review the PM/DM alliance going forward?

After you’ve written down your thoughts, spend time explaining your answers to each other.

You’ll find doing so will help the other one get a better insight into your strengths, weaknesses, and what kind of things you both need from the relationship.

Below are some examples of answers that a delivery manager and I put down when performing this exercise together.

Hopefully, this article and the contracting exercise will help you develop an awesome relationship with your delivery manager, and together, you can create an amazing environment for the team you’re both helping.

Good luck!

Continue Reading

Product management

What is product management, anyway?

No Comments

Hiya – I’m Michael, a product manager at the Department for Education. Recently, I’ve been trying to gain more mentoring experience and, as such, I’ve offered to give a talk to university students about product management.

In putting the slides together for this talk, it got me thinking about what the product management role is and what skills I feel you need to be one.

Defining the product role

Obviously, as it is 2023, my first port of call was to ask ChatGPT.

The view of the borg

According to the borg, “a product manager is a professional responsible for the development and success of a product or product line. They typically define the product strategy, gather and prioritise product requirements, and work closely with cross-functional teams such as engineering, design, marketing and sales to bring a product to market. The ultimate goal of a product manager is to build products that solve customer problems and deliver value to the business.”

Pretty good to be fair. I then thought I’d see if any leading humans in the space could beat it.

Melissa Perri, the author of ‘Escape the build trap’, tells us “the point of Product Management is to create valuable products that customers love.”

Martin Eriksson, co-founder of Mind the product suggests ‘a product manager’s role is to be the intersection between business, technology and user experience.

Taken from Martin’s article ‘What, exactly, is a product manager?’

Marty Cagan, author of perhaps the most popular product book’s ‘Inspired‘ offers ‘”A product manager’s role is to discover a product that is valuable, usable and feasible”.

Stephanie Leue, Chief Product Officer at Doodle, defines a product manager as someone that has “an insatiable hunger to create a customer journey full of wow-moments”.

And Matt LeMay, who wrote the fantastic ‘Product management in practice’, states “to me, being a product manager is all about being the connective tissue, the glue that connects whatever the different roles are within your organisation.”

This got me thinking, how would I define the role?

My definition of a product manager

I believe the product manager is the person that…

  • Sets the vision and the strategy to get there
  • Steers the team’s decision making and aids prioritisation
  • Provides leadership by creating a culture that allows the team to flourish
  • Leads on all communication, especially with stakeholders
  • Represents both the users and the business

Quite a lot, huh?

The Conductor
An orchestra conductor, image from Stepen Oung

A good metaphor would be to say the product manager is like the conductor of an orchestra.

The one stood at the front with the full score. They set the tempo and direction for the group and makes sure all the players are in sync without being the main focal point.

Afterall, people aren’t buying tickets to see or hear the conductor yet it will likely to be considered their fault if the music stops or the players are out of tune.

What skills does a product manager needs?

As product management is essentially a job about leading, cajoling, influencing and communicating with lots of people, one of the key things you need are good people skills. For more on this, check out Ken Norton’s excellent article ‘The Art of Product Management’.

However, away from these soft skills I believe there are other key skills a product manager should have or be working to develop.

Communication

This one is such a biggie that I’ve written a whole article on why communication should be every product manager’s top priority.

In it, I outline that the product management role pretty much pivots on how well you can communicate.

Let’s face it, to be successful in product you’ll need to communicate ideas, communicate progress, communicate with your team, communicate with your stakeholders, communicate with your users, communicate verbally, communicate asynchronously, communicate with… you get the picture.

Either way you look at it, being able to keep others informed and having techniques such as storytelling to help with that is a vital tenant of the role.

Decision making

I firmly believe that making a decision, even the wrong one, is always better than making no decision.

That might sound odd but let me explain.

When a team is stuck at a decision point, getting caught in inertia often results in the team entering a moral-zapping phase of analysis paralysis – this can really suck the life out of a team and lead to stagnation.

On the other hand, making a quick decision will either result in you failing fast and being able to swiftly pivot to the right course or even better discovering you made the right choice first time. Win win.

Now let me be clear. Being responsible for decision making doesn’t mean you have to make these decisions in isolation, or that you have to have all the right answers. It just means that its your responsibility, alongside your team, to use the facts at your disposal to pick which option feels best with the best information you have at that point. 

Leadership

Although the shape of the team you lead will differ depending on the size of the company you work for, it’s a safe bet that most product roles will see you leading a multidisciplinary team.

What is a multi-disciplinary team?

A team made up of different professions, expertise and viewpoints that commonly include a product manager, a delivery manager, designers, developers and user researchers.

As you can imagine, such a diverse teams needs someone in the middle capable of drawing everyone together, creating a vision of where the product is trying to get to and a plan to get it there. 

Being a good leader doesn’t mean you need to dictate everyone’s actions or micromanage.

Quite the opposite.

The best leaders I’ve seen are able to make it clear to their teams what they’re trying to achieve together and then empowering them to navigate the best course to their goal. 

Even with a united team, such varied expertise and viewpoints will lead to people getting distracted or having new ideas that pull away from the direction you’ve set. This is where a good product manager is needed to remind people of what they’re trying to achieve together and keep everyone focused on what’s important.

herding-cats
The life of a product manager, herding cats.

Strategy and vision

Quite often a product manager is brought in to help an organisation solve a problem its facing. Or, in some cases, to help the business decide which of all the opportunities or issues ahead of them, is the right one to solve.

These problems, depending on the organisation or sector, could range from issues such as ‘how can we attract more teachers into the profession?’ through to ‘how can we encourage shoppers to add more items to their basket per transaction?’

It’s up to the product manager to help the team define what the future will look like, how the team can build a working solution to solve the problems its chosen to tackle and what the strategy will be to get the team there.

Let’s take eBay, for example. Their vision is ‘To be the world’s leading marketplace’. They decided to get there, they had to make it as easy as possible for sellers to use the platform so as to ensure buyers knew eBay was the best place to go for their needs.

They didn’t have to choose this route. They could’ve focused on attracting more buyers instead, but without a big enough market, this approach would have been likely to fail.

This decision-making process is a good example of the level of strategic thinking good product management requires.

Analysis and performance monitoring

As I’ve mentioned, a product manager is expected to make decisions but that doesn’t mean that you’ll intuitively have the right answers to hand.

That’s why product managers rely on analysing qualititave data such as user feedback or interview answers or looking into the quantitive data gleaned from things such as analytics software. Taking in as much data as possible and using it to inform your decising making process is a real product management superpower. 

‘Inspiration exists but it has to find you hard at work’ Pablo Picasso

NYC - MoMA: Pablo Picasso's Three Musicians
Pablo Picasso – The OG of product management strategy, image credit to WallyG

This quite sums up my approach to evidence-based decision making.

I always encourage the teams I’m in to submerge themselves in the information at their disposal.

Then, after going through this process, I find that, seemingly out of nowhere, ideas about different approaches we could take appear. Yet these ideas, I believe, aren’t from out of space, but as a result of the team spending time looking at the evidence and then letting subsequent ideas perculate and emerge from spending time in the data. Conversely, I find these moments of inspiration are rare in teams that don’t give adequate time to considering what the data is telling them.

Away from ideation, data analysis is also vital for monitoring your product’s performance. How can you know if you’re solving the problem if you aren’t measuring performance?

That’s why its vital for the product manager to help the team decide what key performance indicators (KPIs) will best to determine whether your product is performing the way its meant to our whether improvements or adjustments are needed. You also need to ensure that your team has thought about the mechanisms that will be needed to measure your KPIs thus providing you with the data you need to analyse to gain your future data-inspired brainwaves. 

Empathy and user focus

Product management often requires skills that are hard to teach, empathy being one of them.

As the product manager is chiefly responsible for representing the voice of the user it is vital that, aided by user research, the product manager has the ability see things from your user’s point of view and use this experience to glean insights into what changes would improve their experience of the product. 

Also, having empathy is a vital and much-needed skill for anyone looking to get the most out of a multidisciplinary team.

Leading such a team means you’ll be tasked with creating an environment in which lots of really talents folk with a diverse set of personality types, working styles, expectations and level of understanding will all be looking to you to set the direction

Being an empath, who is adept at caring for a team, listening and being tuned into people’s individual needs will really help you in creating a happy and focused team.

If you’ve enjoyed this article or found it helpful, please feel free to sign up for the newsletter or share it on social media. I’d also love to hear from you so please feel free to reach out. You can normally find me on LinkedIn or Twitter.

Continue Reading

Communication

Why communication should be every product manager’s top priority

No Comments

Communication is a key skill in many roles but one that is essential to any product manager. 

This post will explain why by looking at 

  • Why communication skills are a must-have weapon in any PM’s arsenal
  • The benefits of good communication and the pitfalls of getting it wrong
  • Some practical tips product managers can use to improve their communication skills

Why it’s a must for product managers to communicate well

Stakeholders, put simply, are everywhere.

What’s more they either expect to hear from us a lot, or alternatively, they don’t know about us but it’s vital that we get their attention for the benefit of our product. 

This is why, whether we like it or not, communication is a key tenant to the product role.

To illustrate this point, I created a quick slide that shows all of the stakeholders I have to manage within my current role. As you can see, there are a lot of them.

Stakeholders I deal with at my role at Department for Education
Some of the stakeholders I have to work with at Department for Education (DfE)

What’s more, each of them have slightly different requirements from you.  

Stakeholder groups are rarely alike, each will have their own unique needs owing to factors such as proximity to the work, investment in the success of your product, bandwidth or level of interest or expecation. 

This means that often the user groups will require a different story about your product. 

Quite often this means that as a product manager you have to tell the same story but in subtly different ways.

Below are examples of some of the stories you may be required to tell.

  • Stories to tell your team to help them build an amazing product
  • Stories to the executives and board to justify their investment and prioritisation of your product
  • Stories to tell the rest of the organisation so you can collaborate and avoid duplication
  • Stories to customers to inspire them to achieve great things.

Understanding your stakeholders and what kind of narrative they need from you (or more importantly you need to provide for them) requires a lot of thought and attention – not to mention different styles of communication both in terms of style and volume of comms.

Not doing the required level of planning and communicating will lead to you feeling swamped and isolated on your stakeholder-engulfed island.

What’s more, not managing these stakeholders through effective communication will lead to some really negative outcomes for you and your team

The pitfalls of poor communication

  1. The team will start to complain about a lack of direction, poor cohesion and confusion. This will lead to inertia, poor morale and slow progress.
  1. Stakeholders will start getting all up in your grill. Stakeholders, when left in the dark, tend to assume the worst. It’s human nature. This will mean that you can expect to start experiencing a lot of challenge and interference as they,understandably, try to get a handle on what’s going on in your team.
  1. Not communicated with other teams in your org will mean that interdependencies and opportunities will be missed. You may also be duplicating effort by working on the same thing as another team and missing the chance to collaborate.
  1. People don’t care about your product. Not communicating well, building interest and buy-in within your org will mean that nobody is rooting for your product and this isn’t good – especially when there are talks around budget and prioritisation.
  1. Users won’t find your product so there has been no point in all the hardwork This one is really important and something that I’ve sadly seem teams neglect to consider and wonder why user’s aren’t magically flocking to a product that no one has told them about by co-ordinating a marketing plan.

The benefits of getting communication right

  1. Your team feel unified, have a purpose, know what they’re doing and are excited about the task
  1. By communicating little and often with stakeholders you take them on the journey with you, they feel in the loop and assured and on the whole let you get on with things
  2. Mastering cross-team communications will mean that blockers, risks or opportunities can be mitigated for or pounced upon.
  3. It’s easier to share ideas o learn from others. And if I’m honest, what I really mean here is that may well be possible for you to steal ideas and sometimes even code from people that have walked the path before you
  4. You have a comms plans that has ensured your product is being used. Through short feedback loops you can iterate and improve upon each release.

Okay but how can I improve my communications?

“Be the person at the front telling everyone else about the plan”

A person delivering a presentation to an audience
Be on the front foot when it comes to comms

This quote was offered to me by a product manager I was shadowing in my first product role at the Department for Education who told me it was the best piece of product advice he’d ever been given.

I didn’t get it at first but I do now and I agree with him, this advice is probably my go to communications strategy. 

For anyone else that is as baffled as I was when I first heard it, let me try to break it down.

This quote isn’t  saying that you you need to be the person with all the answers, but if you don’t go to stakeholders with a narrative about your product, other people, normally stakeholders, start shaping it for you. 

Therefore, your job is to be on the frontfoot by going out to stakeholders with an outline of your plan. Even if it is incomplete, take it out to stakeholders and let them know what you’re thinking.

The beauty of this approach is that you don’t have to have the answers, or commit yourself to a plan. You can frame it in a way that says ‘right now, this is our current thinking, what do you think?’

This opens up a space for stakeholders to either feed into your plan, or give you some extra knowledge or things to look into, or, possibly give you their thinking as to why this plan won’t work’.

All of which are good outcomes that, unless you’re on the front foot communicating effectively, you will miss out on.

This approach also also puts stakeholders at ease. They can see and help to shape your thinking. The alternative is that, not feeling they’re the information will start assuming the worst and will enter the space often dictating what they think needs to happen.

If you want to be in charge of your product’s destiny, make sure you’re leading the charge instead of them by communicating well.’

Use storytelling

“The most powerful person in the world is the storyteller. The storyteller sets the vision, values, and agenda of an entire generation that is to come.” Steve Jobs
“The most powerful person in the world is the storyteller. The storyteller sets the vision, values, and agenda of an entire generation that is to come.”

In order to create your product’s narrative, you need to become it’s key storyteller-in-chief.

As this picture shows, without good storytelling, everything is jumbled up, messy, people can make little sense of what you’re trying to tell them.

With good storytelling then everything can seem obvious. I saw a tweet once (which I’d credit if I could remember who by) that said ‘if you get to a point in which stakeholders agree with the approach you’re suggesting because it seems like the most common-sense decision, then you’ve got your storytelling right.”

That really resonated with me. Your job as a product manager is to bring clarity to what can often be really complex problems – a hard task that requires a lot of skill and effort.

What tools can we use to tell better stories about our product?

Create a product vision

A product vision gives your product a purpose –  without a purpose there is no story.

Example of a product vision We make it quicker and easier for academies to belong to a strong trust So that regional colleagues, teachers and leaders can focus on improving the quality of education
Product vision example

Without sharing the drama the main character (our end users) is facing, the audience (your team / stakehholders) don’t empathize with them enough to go the extra mile and solve their problem. Taking the time to craft an inspiring and clear vision with your team will help you to set out what we’re trying to do, who we’re doing it for, why you’re all bothering to work so hard to do it. 

Having a vision will also help you to bring people back on track when your team goes off in tangents as you can use it to remimd people about the shared goal you’re working towards and prevent the team exploring unhelpful territories.

Embrace visual thinking

Explaining your point using visual tools is a key that will open many doors, especially when you’re trying to communicate complex points. Having a chart, diagram, or an artifact like a roadmap can make getting difficult points across so much easier

Here’s an example of a piece of visual thinking I’ve used in the past to help communicate a product strategy within a previous team. 

An example of visual thinking

The context doesn’t really matter and as you can see I’m not the world’s greatest artist.

However by simply using shapes, icons and formatting alongside some bold phase names our team was able to effectively convey our strategic approach in a manner that was visually digestible.

Having this simple three step diagram enabled our team to illustrate the path we wished to forge to our senior stakeholders whilst inviting them in to comment on our plan, amend it or add any context we might have. A meaningful conversation was had, one that would have felt waffly and jumbled without a visual asset to focus the conversation around

Plotting your outcomes

This last tip is another one a senior colleague at the DfE shared with me. It’s so simple but effective it feels like a videgame cheat code.

Plan your outcomes 

Put short, everyone’s time is precious – so, before every important meeting or call with whatever stakeholder or team mate you’re hoping to influence, you should imagine what the desired outcome is you’d like to arrive at by the end of the interaction.

If you know that you need them to make a decision, help you understand something, or get them to unblock something, knowing what you need from the conversation can help you to prepare in advance to make sure that you can communicate in the most effective way by having a plan for the key points need to hit to drive the conversation where you need it to go.

If you’ve enjoyed this article or found it helpful, please feel free to either comment below, share it on social media or reach out with any thoughts or questions on social media.

Continue Reading