Product Management – Page 2

Setting up a product practice part 2

In my last post I talked about my ambition to work on our team’s product practice. I started by focusing on what problems we might solve within the organisation.

As a next step, I needed something tangible that described a mature product team. Like a sort of toolkit that would help us agree on the role and work of a PM.

After some research, I decided to go with Matt LeMay’s CORE framework (Communication, Organisation, Research and Execution) because it is sufficiently broad to be applicable to our circumstances. It doesn’t assume that customer = user, nor does it assume that you’re selling your product at all.

It was also a personal choice, because I like how he conceives of product management as a discipline. I would really recommend his book Product Management in Practice, where I got the CORE framework from.

Discussing the CORE framework in a workshop

I wanted to explore the framework within a workshop setting with my team. I didn’t have the time for them to read the chapter on the topic, so I decided to adapt it for my purposes. I synthesized and adapted his framework to our reality so that we could use it as a conversation starter.

Below are my sections from the workshops for each element of the framework.

Communication

As Product Managers, we are constantly communicating. With our product team, stakeholders, other teams, sponsors, users… anyone who is remotely impacted by our product

Why?
To create alignment and understanding between teams. We prefer clarity over comfort, that means we’d rather ask an uncomfortable question than run the risk of things not being clear.

How?
– Formal and informal
– Written and oral
– Active and passive (Listening is also part of communicating)

Some of the tools for that:

coffee
presentations, demo, show and tell
roadmaps
release notes
posts on internal networks
Jira
styleguide

Organization

As Product Managers, we organise other people’s work. We make sure that our team knows what to do and why, without telling them how.

Why?
We know what problems need to be solved, but we have to rely on others to define how. In that we need to build a common understanding and work to build good collaborative processes. Ideally we want the team to understand the mission so well and collaborate so well that we become redundant.

How?
– adapt product development methodologies to our reality
– improve processes and practice

Some of the tools for that:

user stories and acceptance criteria
Ceremonies: retrospectives, stand-ups, planning
Workshops: roadmapping, Prioritisation, kick-off, user-journey mapping
product development lifecycle (discovery, alpha, beta, live)

Research

As Product Managers, we learn about our users’ reality every day. We are intrinsically curious and ask ‘why’ more often than a 4-year old.

Why?
What our company cares about and what our users care about are different things, so we have to be a relentless advocate for the latter.

How?
– seek and synthesize multiple perspectives and sources of information
– never take anything for granted or at face value
– give voice not only to your users immediate transactional pain points but also to their broader and more complex realities

Some of the tools for that:

user research and user testing
surveys
market and competitor analysis
product canvas
customer meetings
data analysis
5 WHys
Assumptions mapping

Execution

As Product Managers, we are willing to do whatever it takes to help our team and our organisation succeed because delivery of value is paramount.

Why?
We care most about value being provided, and there is no work beneath, no work above. If it fits with no-one’s role, and it needs to be done, then it’s our role.

How?
– bring in the donuts and team motivation
– focus on where the gaps are and fill them

Some of the tools for that:

food and casual time
retrospectives

Next steps

The next step is a workshop with the team, to first review the problems, then inspect and discuss the toolkit, before in the third step reflect on what product skills we should develop and what tools we should adopt to help us address our problems. More on that in the next post…

Read part 3 of setting up a product practice.

Setting up a product practice – part 1

What does product practice mean to you? I have worked in organisations where product teams and product management were fairly well defined. We often had debates and discussions about the product role, but it was within an overall framework of expectations and understanding of what the product role did.

A few months ago, I started a job where that did not really exist. I lead a team of 6 product managers with about 15 products (depending on how you count). And while there are other product managers in the organisation, they are in other departments and we have few links with them.

Stating the problem

As I was learning and observing, it felt like the PMs weren’t PMs like I had known them elsewhere. Some things that I considered fundamentals seemed to be missing. For example, there didn’t seem to be an easy way to find information on what was planned for the products.

I felt I had been hired to bring in a strong idea of product management, but I didn’t want to blindly impose my idea of what a product manager should do. I know that PM roles tend to be quite different depending on the circumstances of the organisation and the product. Therefore I found it hard to pinpoint where there was a gap in product practice, and where it was the idiosyncrasies of the organisation.

In order to disentangle “what a product manager should do” versus “what the organisation needs”, I eventually reframed the question to.

How could product practice and skills answer some of the organisation’s most pressing problems?

In 2021, I want to trial different approaches to answer that question and find a product practice that works for us. I plan to use books and blogs for inspiration, but let my team construct the practice.

There’s two objectives in this:

Help the organisation with its most pressing problems
Build a mature product team

Objective 1: help the organisation’s most pressing problems

In my initial assessment, I identified a number of problems which all lead to value not being delivered to the users.

Alignment – It was hard for me to gather information on the products when I started, and unsurprisingly that it’s also the case for our colleagues whose primary focus isn’t the product but who are impacted by product developments. I’ve already seen several teams take decisions at odds with the roadmap. They eventually realised what was planned, had to reverse decisions and change plans, sometimes doing twice as much work. Each situation was different, but in every case there was a lot of frustration for the product manager (who felt undervalued/ignored) and for the team in question (who felt out of the loop and undervalued).

This lack of alignment has primarily resulted from considerable team changes (people leaving and arriving), the move to working from home, and also the increased pressure the team has felt this year. Things are finally stable enough so that we can address this issue.

Severity: Very High. It’s systemic across our products, and the frustration caused is starting to impact people’s wellbeing at work.

Complexity – It took me a while to fully grasp what we were doing and I still find it hard to communicate what we do and what we’re working on. There are so many initiatives, so many stakeholders, my brain continues to struggle with containing all the elements. This is to some extent on the products, but also within the department in general. The main issue here is that it makes communication hard, which in turn makes it hard to align people.

It might be difficult to make away with complexity within the short and medium term, but I think we can work on how we communicate it, and hopefully influence others to help reduce complexity overall.

Severity: High because it affects alignment, but also it’s not all in our control

Delivery – Delivery of software looks different for our different products, partly due to the fact that we manage both custom products and off-the-shelf solutions. For some of them, we’re operating in continuous delivery, but for some there are elements of waterfall practices and big bang releases, and all the added risk it adds.

Severity: Not a problem for all products, but definitely a risk for some (including those our important stakeholders are watching).

User-focus – Evidence around user needs and behaviours are inconsistently used as drivers for our roadmaps. While we work with user researchers and UX designers, they are stretched across our products, and fairly often, we see management wants, political negotiations and best guesses make their way into our roadmaps. Often because we don’t have the information to counter their arguments.

Severity: Not a problem for all products, but something that can be improved, and avoid investing in features that later on require significant rework or get killed off.

Objective 2: a mature product team

The idea of what a mature product team looks like is much more blurry for me. I have already started digging into industry literature, reflected on my own experiences and used fellow PMs elsewhere as sounding boards. This is definitely still macerating in my head and will likely be the subject of the next post.

My plan is to build a rough idea of ‘product practice’, so that we have things to pick from when building ours.

What’s next?

Once I have my rough idea of a product practice, I plan to do a series of workshops with my team of PMs. First to validate my idea of the pressing problems, and then try to build the first element of our product practice around one of the problems.

Read part 2 of setting up a product practice.

Building Knowledge Management products

You may want to start by reading part 1 of the series: What is Knowledge Management and why should you care?

Our users are our colleagues. Whether they are working in games, human resources or IT, they require an entire ecosystem of products to help them access the knowledge they need.

What are the products?

We map our products from the user’s perspective. Our products form 4 concentric circles, starting from the user in the centre moving outwards to ‘my team’, ‘my networks’ and the outermost layer ‘the company’.

	Me Tools with information relating to only you. They help you: – store personal files – take online courses – learn about your work habits
	My team Daily tools to collaborate with an immediate team. They help you: – call and chat with your team mates – document your work – manage tickets – share and access team files
	My networks Tools which link different networks of people who have something in common (eg location, profession, interests). They help you: – access information related to your office building or studio – find like-minded people to chat to – learn about your fields of interest
	The company The platforms and data infrastructure that underpin all the other tools. They help you – access company-wide information – search across and navigate between all the different spaces – get a personalised experience They also help our team manage internal tools and platforms.

Combing in-house products with off-the-shelf solutions

The tools we manage aren’t all products that we’ve built internally. In fact it’s about a 50-50 split between products developed in-house and products we’ve bought and implemented within the organisation. The Software-as-a-Service (SaaS) market for internal tools is vast and offers many opportunities to address user needs without investing in our own tools.

Regardless of your products, the product manager’s role is two-fold:

to ensure that we’re providing value to the users and,
to develop a common understanding on what we are (and what we are not) delivering, for the team, our users, partners and stakeholders.

However, the types of activities our PMs do vary depending on whether they’re managing in-house or SaaS tools.

Different to a classic PM role, PMs working on SaaS tools will closely monitor our vendor’s roadmap and in some cases seek to influence it. They will review new features, working with user researchers to identify how these may impact our users’ experience. They will also consider what integrations with our ecosystem are necessary. They will then collaborate with IT infrastructure teams to manage the release of features and communicate these changes to users.

Focussing on the employee experience

We want our employees to be able to work more efficiently and produce better quality work. This means we think a lot about the ‘noise’ our products create. We can’t have products competing for our users’ attention. So we make sure that our tools are unobtrusive to avoid distracting them from their daily work.

That’s why it’s important that we design an ecosystem based on the employee experience and their journeys across our tools. We create our roadmaps based on their needs and within user journeys, rather than focussing on individual products.

Adapting to changing needs

Knowledge Management is a rapidly evolving field. Even in normal times, we’re having to adapt to new user needs and disruptive tools in the market. The recent health crisis has only increased the speed of change. The rapid shift towards working from home in early 2020 meant we had to quickly adapt.

New behaviours and expectations continue to emerge and we’re certainly expecting more change. Therefore we are closely observing our users, as we focus on building a digital workplace where all employees can focus on what’s important because they have the right knowledge at their fingertips.

What is Knowledge Management and why should you care?

Knowledge Management, whether you have a department for it or not, is a crucial part of how companies function.

In an organisation with thousands of people working across the world, knowledge is not only created constantly, but it is also shared and consumed with near immediacy. Our designers are coming up with new ideas, our engineers are solving technical challenges, and our marketers are uncovering new trends in the industry.

Managing that knowledge effectively allows companies to achieve better performance, because it avoids duplication and promotes the use of best practices ¹. These mean cost and time savings for the organisation, making it more competitive.

Good knowledge management not only benefits the company, it also creates a happier workforce.

Our users expect to have the right information at the right time and it’s our role to enable that.

I dare you to recall the last time you trawled through never-ending search results across document management systems, email or your intranet… looking for THAT document that you need. That is the pain we try to relieve.

You’re not alone. Knowledge workers waste between 20 and 30% of their time searching for information ². A particular study found workers to be spending 1.9 hours a week searching for but not finding documents and 1.5 hours a week recreating documents that already exist ³.

We want an organisation where knowledge can be reused with near-immediacy to enable our employees to work more efficiently and produce better quality work, while helping them flourish in their job.

Therefore our product vision is to build a digital workplace where all employees can focus on what’s important because they have the right knowledge at their fingertips.

This is part of a series on being a product manager in Knowledge Management. See part 2 on building Knowledge Management products.

———-

Footnotes

There’s lots of stuff in academic literature about that. You could start with Abubakar et al, 2019.
See ‘Employees spend more than 25% of their time searching for the information they need to do their jobs‘ and ‘Do workers still waste time searching for information?‘
Bridging the Information Worker productivity gap in Western Europe: New challenges and opportunities for IT

Starting as a manager of product managers

Inspired by a former colleague’s blogpost about things to do as a new product manager joining a team (which has now become a Trello board) and because I have just started a new role, I thought to add to Steve’s piece by reflecting on what to do when you start as a manager of product managers.

I started nearly 3 months ago and while this period is often referred to as ‘onboarding’, it’s been much more a ‘fact finding mission’.

I’ve always been convinced that Product Management is 50% story-telling, and therefore it’s probably no surprise that the classic ‘What, Why, When, Where, Who, How and How much?’ helped me structure my thinking as to what questions to ask.

What: the product(s)
Why: the strategy
When: natural lifecycles
Where: the company
Who: your team and your stakeholders
How: product craft and agile working
How much: the budget

What: the product(s)

Getting to know the products your team manages is the pretty obvious thing to do. You may already be familiar with the product, or you at least played around with it during the recruitment process. Though, if like me, you’re working on tools that aren’t customer-facing, this might be your first real interaction with the products.

The over-arching questions I had about the products were:

Who are the users?
What user needs does it meet?
What is the vision?
What are the main metrics?
Who are your key stakeholders?
What is the technology?
How well do we understand the product usage (data and user research?)
What is its adoption?

Why: the strategy

Here I worked my way down from understanding the company strategy overall, then understand how my department fed into the overall strategy and what our strategy was.

I also tried to understand the rate at which these change. Looking at previous strategies will give you the historical context as to why things are the way they are and an idea of how often things change.

When: natural lifecycles

All places of work have their natural rhythms. They are in part imposed by financial and fiscal policies but also show up in the rate by which organisational change happens and how often people move roles. Beyond looking at budgeting cycles, trying to get a sense of the rhythm isn’t always straightforward.

Some of the questions I had were:

For what period do objectives , strategies and budget get defined? What ceremonies mark these periods?
What is the time someone typically spends on the team or in the department? How long have my colleagues been here? Have they always had the same roles? What is the rate of change here?
How long has the department existed in the shape it does now?

View the autosave

Where: the company

Beyond its strategy, there’s many things that you need to know about the company, and the higher you are in seniority the more important it is.

Depending on the size and age of a company, this can take quite a long time. In a big organisation you’ll probably never get to the end of this before something changes.

My questions at the beginning were about:

The industry we operate in (as it was new to me)
- how does my company/organisation compare to others?
- what are the main challenges and trends in the market?
Company culture
- What behaviours get rewarded?
- How do new initiatives get put forward?
- How candid are people in their approach?
Company structure
- How does my department fit in?
- What other parts of the organisation do we work with?
- How is power distributed?

Who: your team and your stakeholders

Of course, a huge part of the first few months is getting to know the people you work with. Starting with the product managers and the people who make up the product teams (design, dev, research, QA etc).

I asked the people I directly managed about:

Their background: How did they arrive to product?
What are their strengths and points of growth?
What are their biggest challenges?
What do they love/hate about the work?
How do they rate the collaboration with others?

And I try to get them to know personally as well. This can depend a lot on each person, as we all have a different level of comfort when it comes to talking about personal stuff at work. I won’t force a conversation about their personal lives, but when it feels good, I don’t hesitate to engage in conversations about things like family, hobbies etc.

I had very similar conversations with the people who are in our product teams as I had with the product managers, especially if I will work with them directly. I won’t have the same intentions, as I don’t have managerial responsibilities here. But understanding how they want to develop is important so that I can find opportunities to help them grow.

Then there’s the stakeholders. This is a whole subject in itself of course, but you’ve got to start somewhere. First I tried to understand from my team who the major stakeholders were, how they were impacting the products. Where they had stakeholder maps, this was really useful.

Next step is meeting them. This can take a while, so I had to do this strategically. I asked both my team and manager for advice on the order in which I should meet people. Of course they didn’t quite match up, but based on their recommendations I was able to put together a plan.

Indeed, some stakeholders were perfectly happy to meet with me when I had very little knowledge about our team, products, company etc. They were very patient to help me understand how they fit in and would answer any questions I had. Others were best to leave for a bit further down the line. They wanted to gauge your approach, suss you out, and it was better to come somewhat prepared.

How: product craft and agile working

Like for many other managers of product managers, I also have a responsibility over the overall product discipline in my area. So understanding how we worked was crucial to see how I can bring about improvements.

The main questions I had at the beginning:

How and where do we communicate about our products?
Where and how do we gather evidence to inform our decisions?
How do we collaborate with other disciplines?
How often do we release code?
What expertise is key for our product managers (technical, market, users, all of them?)

How much: the budget

This is not something you want to leave for last, because it’s the thing that can really hinder you if you don’t pay attention. As a manager of product managers, you’re much more likely to be involved in defining budgets or at least getting a say in where money gets spend.

It’s crucial to understand when the budget gets decided and by who, and understand:

When do you need to start making your case for money?
How much flex is there in the current budget?
How does it get adjusted?
Where are we now in terms of spending?

In conclusion

**This was me at the end of every meeting**

Above is probably only a fraction of the questions that I asked and will continue to ask. Treating the start on a job as a quest or a discovery really helped me frame my thinking and being ok with not knowing. The free pass you get when you start a job to spend all your breath on questions, is a huge opportunity.

Also… I sometimes fell into the trap of saying ‘I have a stupid question’ which made me instantly cringe inside. No question is stupid, there’s no need to belittle myself. I therefore created a ‘stupid question jar’ with a euro for every time I said that out loud. I’m happy to report that at the time of writing there were only 2 euros in the jar!

What about a squiggly product career?

‘What are you building here?’ was an interview question that dumbfounded me 5 years ago. That day, I mumbled an incoherent answer.

In hindsight, I have a better response: a squiggly career*. With every new product job I have changed industries, working across non-profit, legal, government and now gaming. I have chosen to focus on the product craft without settling on a specific industry.

Here’s my thoughts on what’s good/bad or easy/hard about that approach, as well as some thoughts on how to make that choice for yourself.

Employers and recruiters may say ‘become an expert’

While this isn’t everyone’s view, I have repeatedly heard from companies and recruiters that they look for PMs with the right industry experience. My most recent example is a recruiter from Spotify who shared some insight into how he selects CVs.

He considers 6 seconds a generous amount of time to spend reviewing a CV. Being time-poor, beyond focussing on experience as a product manager, he requires relevant industry and domain experience. That means that it’s not just music/ subscription services you should know about, but also he’d like you to have experience in the domain you’re applying for (eg payments).

When asked about what to do if you didn’t have the necessary industry/ domain expertise, he said be prepared to either go in at the same level as you are or potentially go down in seniority. Also, you should invest a lot of time in learning about the domain/industry before applying for the role and be ready to make a pretty strong case as to why you are pivoting.

What I also sensed in his answer is that his expectation was that you would only be pivoting that one time. You should show your commitment to focussing on this industry and domain for the longer term.

I can definitely see where he is coming from, and for a company like Spotify with hundreds of PMs and a high appeal, maybe having these types of requirements makes sense.

I can also see it from a PM’s perspective – becoming an expert in an industry can be highly stimulating when it’s your passion.

However, I know it’s not for me. I never had a 10-point plan for my career. When I changed jobs it was because the next opportunity was something I was excited about and where I would learn a lot, not necessarily because it was an obvious choice.

Why it’s worth it

In the short term, a squiggly career may be hard. It requires resilience, an ability to learn, and a true openness to new ideas and ways of working. However, it also gives you the exposure you need to become really well-rounded and develop a broad perspective.

Through my squiggly career, I have not only explored different domain, I’ve also worked in companies of different sizes, on both very technical things as well as transformation/change management projects, have managed a team on a shoestring, and have had a well-resourced team.

This means I am now extremely adaptable. I have learned the advantages and disadvantages of these environments and am able to adapt to a new role and bring in the things I have seen work elsewhere.

Through these experiences I have become really good at being thrown into new things. While I get stressed and nervous like everyone else, uncertainty isn’t what scares me. I have acquired techniques to make sense of uncertainty and ambiguity, and I have the resilience to know that I have been in this situation before and will be able to deal with it, and I know how to support my team through it as well.

Some top tips on making a squiggly product career work for you

1. Decide whether this is really what you want

It’s hard work. And from a logistical perspective, it also requires you to be in a place where there’s lots of product jobs, or you’ll have to be flexible with either working remotely or be willing to relocate.

I was in London for my early career, and am now in Paris, and that has made this approach much easier.

Life has many different priorities, so this might just not work for you.

You may also find that you particularly love a domain. If that’s the case, that’s great, go for it!

2. Get really good at learning

A growth mindset will support you through the different stages of your squiggly product career because learning has to be at the centre of everything you do.

The most crucial part is to learn about yourself and really understand how you learn. Then it is to be intentional about your learning. Have clarity on what you need to learn, don’t let the world happen to you.

3. Build a strong narrative

With a squiggly career your job titles and previous experience are unlikely to tell a coherent narrative. You need to take charge of your story, and make sure you have a good idea of who you are and what you care about.

Finding the golden thread throughout your different experiences can help create that. Add that to your intro on your CV or LinkedIn, but also have that ready when someone asks you why you want a job, or ‘what are you building here?’.

4. Keep your network going

Your professional network is a crucial aspect of your career development, regardless how squiggly your product career is.

While you may remain connected to your product network, changing industry can mean you lose touch with people you know from previous roles. This may be ok, but it’s worth being intentional about who you want to stay in touch with and make efforts to do so. Squiggles don’t mean you can’t return to a previous company or industry.

*When I was trying to describe my career, I first thought to call it a ‘portfolio career’, but then I came across the squiggly career’s podcast. It’s a brilliant podcast by Amazing if that strives to make work better for everyone – particularly in the context of careers that don’t follow a linear path.

So I thought to name the blogpost squiggly careers to reference Helen and Sarah’s excellent work – but also because I realised that it reflects my career better than ‘portfolio career’.

Why do PMs keep asking existential questions ?

A couple of weeks ago I wrote about feeling like a product fraud, which got me thinking about what this PM archetype is that we imagine the role of a typical Product Manager to be. And then, considering how many blogposts I have read about that particular question, I wondered why we spend so much of our time pondering about what our role is and should be.

There are hundreds of books, blogposts, podcasts telling us what product management is, or alternatively what product management isn’t. I am curious as to why we seem to question the role over and over again. So I explored a few reasons that I can imagine.

A recent discipline

It is a recent discipline, and it’s still being shaped by this ever evolving world. But product managers existed in a pre-tech world as the person that would care about a product from all angles, that would bring together the manufacturing and marketing of a product. I wonder whether pre-Medium and pre-Twitter product managers asked this many questions.

The world of work is changing

The world of work is changing and it’s particularly affecting the industries that Product Managers are working in. But then again technology has changed most jobs.

If most jobs are changing, are all professionals going through this? A whole industry has been spun up to answer what product management is or should be. I don’t know other industries so well, but do other job families ask themselves ‘But what is my job?’ so frequently as we as PMs do? I’ve never heard any of the developers ask that question. But I might simply not know what I don’t know.

Diversity of experiences

To come back specifically to product managers. I think another challenge is to conciliate the experience in a small startup compared to a large organisation. While there’s certainly an overlap of skills, what you’ll be doing day-to-day and the overall responsibility could well be very different. So the product community is trying to figure out what the overlapping skills and responsibilities are.

Is it because we’re fighting for legitimacy

I’m sure all PMs have faced remarks that play down the role of product managers. I still remember someone saying ‘I don’t understand why Product Managers get paid so much, they don’t do anything’ (and I’m aware that I should just get over stuff like that), but really it indicates that we as a discipline may feel the constant need to define ourselves in order to justify our place at the table… or rather at the Kanban board. In multi-disciplinary teams the boundaries of roles get easily blurred and since we’re not one of the ‘makers’ we struggle to point at something to say. “There- that’s what I did!”.

Always delivering value

To put a more positive spin on this, maybe it’s also because our day-to-day job is always making sure that our team delivers value. It could be that we have internalised the question of value so much that we need to constantly re-appraise whether we as a discipline are bringing value to the team. In a way this is my favourite reason because it paints the conversation about Product Management as a way for us to stay accountable to ourselves and always making sure that our role is needed.

Do you have any thoughts about why we ask ourselves what Product Management is or should be? I’d love to hear your views!

Feeling like a product fraud

Throughout my career as a Product Manager, I’ve had several existential crises, thinking that the job I was doing did not reflect what I imagined a Product Manager should be doing. Several years into being a PM, I came to realise that no-one really does this ‘typical PM role’ I imagined, because it doesn’t exist in the real world, and that is the beauty of the job.

I’ve listed some of the moments in my career where I’ve felt like a fraud and why – with hindsight – I now know better.

Because there are no developers on my team…

When I started in my current role, my team was very odd, it was multi-disciplinary, but lacked the roles I was used to — developers and QA engineers, or a visual/UX designer. My team had a user researcher, a delivery manager (akin to a scrum master) and a content designer. Needless to say I was rather clueless as to what I could do with that team constellation. Building anything would be rather tricky!

But then, I was working on a product that wasn’t yet built and our team was this shape because we didn’t understand the problem space at all. Throwing a team of developers at the problem wouldn’t help, but the user researcher and designer were the right people to get the team to a place where we understood the problems better. And a few months later, we were ready to welcome a developer into the team and start building!

By that point, I had understood that as a PM I was just as qualified to set the vision and advocate for our users in a team without developers. The skills of product management equally apply in a team with different types of expertise — be that designers, researchers, data scientists or even policy experts.

Because I am also doing UX design, user research, QA and making sure the printer doesn’t run out of ink

Like many, when I first learned about product management I was in a job already acting as a PM. I was translating the needs of our users and stakeholders into stories and providing the necessary context for our developers to build our product. However, next to that I was also doing a lot of other jobs, such as drawing wire-frames, doing user research and testing the product. It was difficult to feel like a legitimate product manager.

However, looking back this was a wonderful opportunity. Not only was it my route into the role of PM, it has also given me a huge appreciation for some of the other disciplines. In small startups, this can certainly happen, and there are also plenty of project or consultant roles that are disguises for a product role. So forget your job title and feel included in the product community.

Because I am executing orders from senior management…

As a PM you can be in a situation, where you want to represent your users but senior management is much more keen for you to just do what they say. You can fight back with the user research you do and the analytics, but ultimately if senior management doesn’t offer you the freedom to build the product based on your users’ needs, then they are simply not doing their job right. And it certainly isn’t on you. I was legitimately a PM, I was just in the wrong place.

Have you ever felt like a product fraud? I would love to hear your experiences!

MTPcon 17 — theme 4: designing for the future

Two of the talks at MTPcon were concerned with designing for our future. On the one hand Amber Case was advocating for calm technology, while Josh Clark was talking about considerations for designing machine learning and big data products.

Amber Case, who is a scholar at MIT, started talking about a few worries of hers: a connected kitchen, where every piece of the kitchen would be using a different technology system with its own username and password, asking for your attention all the time, and were you to move, you’d have to get all the credentials from the previous tenants, making sure it works with your current devices… it all seems very disruptive.

Amber Case is an advocate for Calm Technology and she has a set of rules she to define calm technology:

technology should not be intrusive, it should remain in the background
technology should only be there when you need it
tech should inform and calm
tech should amplify the best of technology and the best of humanity: machines shouldn’t act like humans and humans should act like machines
technology can communicate, but it doesn’t need to speak
technology should consider social norms
the right amount of tech is the minimum amount to solve the problem

Josh Clark also had the future in mind, thinking about what rules we should apply to build big data products and he had a few recommendations as well

Principle 1: embrace uncertainty. Machine learning products such as image recognition technology has still a lot of short comings — for example this one:

Clark suggests that we need to embrace the lack of knowing instead of building the perfect machine that is always right. Here is his suggestion for the same image:

Principle 2: improve the data. Another challenge of our time is the quality of the data that we feed into big data products. We are running the risk of teaching it pre-existing prejudice and inequalities, reinforcing structural inequality rather than creating a level playing field. Algorithms are in no way objective. They represent the agenda of the agenda of the person who is behind them.
Principle 3: responsible data gathering. As we are getting better at gathering lots of data, we need to be more responsible in the way we do it. We need to be loyal to the user, and take responsibility, as your product will have the values that you put into it.

More MTPcon 17 themes:

(1) the contribution of leadership

(2) creating space and opportunity for teams to perform

(3) rejecting or embracing the past

MTPcon 17 — theme 3: rejecting or embracing the past

Some of the speakers touched on how we deal with the ideas and ways of the past. Jake Knapp’s design sprint methodology is framed as a rupture from the past, from the ‘default’. Don’t just do design the way you’ve always done it, break from it. Using the ‘design sprint’, a one-week exercise for a cross-functional team to tackle a very specific problem. According to his method, you spend each day on a different activity, focussed on quick decisions and quick testing and learning.

In terms of breaking with the past, Barrie O’Reilly quoted management consultant Gary Hamel:

‘Right now, your company has 21st century internet-enabled business processes, mid-20th century management processes, all built atop 19th century management principles.’

And this is where we need to be breaking with the past and old ways of working. However, we shouldn’t necessarily be breaking with what we were thinking about in the past.

Scott Berkun, who was the more ‘out of the box’ speaker of the day, suggested that when searching to solve problems, we shouldn’t assume we are working with a new problem. For Berkun, all ideas are made of other ideas. And we should study the history of a problem to find new ideas for solving it. Seeing if any ideas were abandoned or transformed, and adapt them to today’s thinking.

More MTPcon themes:

(1) the contribution of leadership

(2) creating space and opportunity for teams to perform

(4) designing for the future