Thinking Out Loud [Product Management] – Learning about product management, out in the open!

Product for Good – the first meet up, what happened and what’s happening next?

02/10/2024 No Comments

Firstly, what is Product for Good?

Product for Good is a community of product people that believe the product role affords us the agency to do societal good.

This idea had been knocking around my head for a while. I put an initial LinkedIn post out to test the water and see if there was any interest.

It turns out there was, so I created this blog post that outlined some of my rough thinking alongside a Google Form for those interested to sign up.

The result was we had twenty five socially-conscious product folk sign up and we put a date in for our first meeting.

This blog post seeks to publicise what we discussed in that meeting and outline what we want to achieve.

I want to do this for a few reasons.

To keep a record of what we talked about for those in the community that weren’t able to attend.

To work in the open to promote our work for those that haven’t come into contact with us but would like to be involved or aware.

What kind of people signed up for Product for Good?

Well, in short, a bunch of really good eggs.

Don’t believe me, take a look at some of the reasons people gave for wanting to be involved.

To be involved in influencing digital products to do better across the board.
Firmly believe that tech products have huge potential to deliver large scale good!
I would like to share knowledge on digital sustainability.
Product has huge capacity for good, but interested in how we can create action
As a product manager, I believe we have a unique opportunity and responsibility to drive meaningful change. Our role positions us at the intersection of innovation and impact, where we can champion ethical practices and create products that genuinely improve lives.

People came from a range of organisations including Marie Curie, The Open University, the BBC and DEFRA, to name a few.

What was discussed on the call?

The Google Form asked folk to say what topics they thought the group should cover – there was a lot of synergy in people’s answers.

Suggested topics to tackle broadly fitted into four categories..

Tech / Product Ethics
Sustainability
Protecting individuals / users
Putting a value on not-for-profit work

During the call we voted on which we’d like to focus on first and the group decided to, initially at least, focus on Tech and Product Ethics, followed by Sustainability. Awesome.

The group also talked about how they’d like the group to operate.

We decided we wanted to…

Bring like-minded people together to deliver impact, raise awareness of best practices, and do meaningful work as a collective.

That it was important to us to have clear goals, to commit to doing what we say we plan to do, to seek external connections and partnerships and to be respectful and open minded.

We decided we’d meet online on a four-week cadence, use Padlet to store our ideas / work / things to research, and that we’d communicate using a WhatsApp group in between our regular online calls.

What’s next?

On the call we outlined our immediate plans.

Firstly, we’d like to codify an actionable set of tech / product ethics that product managers, and subsequently their orgs, can use to improve their products and the lives of the users and ecosystems in which they exist.

We’d then like to do something similar in the sustainability space.

Luckily, a member of our budding collective has spent a considerable time conducting research on ethics in tech. We plan to learn from this person and see if we can use the Product for Good community as a vehicle to turn that research into meaningful action and change.

If this all sounds like your bag, fill out the Google Form to register your interest and hopefully we’ll be seeing you on the next call to be part of the action.

Product for Good

Product for Good – a call for product people to unite for societal impact!

03/08/2024 No Comments

Graffiti on a wall saying 'together we create'

This blog post is a call to arms for ethically-minded product people to unite, knowledge share, and up-skill so we can use the agency our role affords for the betterment of each other and society at large.

Get involved, here!

Does Product for Bad exist?

In 2021, Frances Haugen, a product person turned Facebook (now Meta) whistleblower, told us that she believed the company put profit before public safety and that the organisation was turning a blind eye to internal research that asserted the platform was contributing to..

The spread of misinformation
A rise in online hate and division
Poor teenage mental health

“The thing I saw at Facebook over and over again was there were conflicts of interest between what was good for the public and what was good for Facebook. And Facebook, over and over again, chose to optimise for its own interests, like making more money,” she said.

This seems to be a rather nailed on example as product for bad (sorry to any Meta PMs).

If Frances is correct, it would seem Meta is happy “in the knowledge that its platform is causing harm to society, and actively avoiding fixing these issues due to a desire to turn greater profits.

So, what is the alternative?

I presume, maybe naively, that many of us opted to become product people based on a desire to create things, improve lives and change the world for the better as opposed to a pure profit motive.

I also suspect that many public sector product people avert the lure of the private sector dollar due to a commitment to public service whilst lots private sector product folk would love to be able to prioritise things that improved society rather than just turned a profit.

And whilst there are lots of amazing Tech for Good initiatives, I wonder if we could think more specifically as to what we as product folk can do to?

After all, as product people, we are the prioritisers – the ones tasked with influencing and challenging stakeholders. I believe this role provides us a unique opportunity to put things on roadmaps, or introduce ways of working that synergise an organisation’s goals with public good.

I firmly believe we can and should use our agency to ensure our teams and our organisations are building the right things in the right way – in ways that protect privacy, encourage inclusivity and aren’t causing unnecessary harm to the planet’s finite resources.

We have an opportunity to be forces for good but how?

How can we make changes to our individual practices and the habits within our organisations to drive ethical innovation?

Hopefully, in the right departments or companies the product work we do itself can benefit society.

But I wonder whether we can go further?

If the product community were to focus on upskilling itself with the skills and knowledge to create, manage, and scale tech products that truly make a difference, or to work within orgs in an ethical manner, what an impact could we make?

And what sort of things would we have to know and learn to leverage technology to drive positive societal impact?

Want to get involved?

This is just a kernel of an idea on a topic too big for a single person to do anything meaningful with.

Therefore, I’d like to see if others out there would like to join forces to start discussing how we can collectively make a difference.

As a starter for ten, I imagine we might start with a few discussions such as…

If there was a course on Product for Good, what topics would you want/expect it to cover?

If all public sector / private sector product people took this course early in their careers, what impacts can you imagine for society?

If this sounds like something you’d like to be a part of, fill out this Google Form and let’s see where the journey takes us.

Design Systems, Product management

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

12/05/2024 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.

It’s helped us to figure out where we should focus our efforts
It’s brought us closer to our users, on many cases on first name terms. ie short feedback loops
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.

Careers, Product management

Career change – how do I break into product management?

23/03/2024 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.

Careers, Product management, Start-ups

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

23/01/2024 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

Careers, Product management

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

13/01/2024 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

Product management

First month in a new product role!

21/06/2023 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 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.

What are this team’s superpowers?
What things could this team improve upon/ what are it’s key challenges?
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…

Explained that I was giving this update as I believe in working in the open, overcommunicating and eliciting feedback early.
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
I then went over the murder wall, the questions I had, and then shared the six areas of focus that emerged.
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.
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.

MVP, Product management

Define your MVP with User Story Mapping

28/04/2023 No Comments

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)

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

Government Delivery, MVP, Product management

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

03/04/2023 No Comments

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.

Product management, Relationships

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

09/03/2023 No Comments

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.

What does [Insert PM’s name] expect from [Insert DM’s name]?
What does [Insert DM’s name] expect from [Insert PM’s name]?
What would make working together awesome?
How will we deal when conflict or challenges arise?
How do you like to receive feedback?
What are your strengths?
What are the areas you’d like to develop?
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!

1 2 Next »