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.
A number of the speakers touched on ideas and methods to create space and opportunity for cross-functional product teams to perform.
Sarah Nelson talked about the importance of space and the working environment. As culture shapes space, shape also creates a culture. And shape limits or enables the kind of interaction that will enable a team to work together effectively. Sarah spoke about the IBM studios initiative that gave teams the ability to make the spaces their own. It was a strategy to make the transformation to small semi-autonomous cross-functional teams explicit in this huge organisation.
Another important aspect is decision-making. Teresa Torres talked about an example where she struggled to get her team to make a decision together, because they were coming from such different perspectives, that they couldn’t compare their ideas like for like. She developed an opportunity solution tree to help map the user needs, and help prioritise these, before discussing ideas how to address one particular need.
Jane Austin from Moo spoke about their ‘quads’ team comprised of Product, Design, Dev and an Agile Coach. To make decisions, only one or two people from each discipline are required — they talk about consent, not consensus. Cross-functional teams work together at all times, design aren’t only required at the beginning, design happens at every step of the process, and research is a team sport, everyone participates.
Barrie O’Reilly argued that high-performing organisation reduce learning anxiety. They allow people to learn new things without the fear of retribution. Added to that comes Scott Berkun’s argument that our minds are naturally creative. We all have the capacity to be creative, all we need is the motivation, which comes from a specific problem and the opportunity, which is the permission to fail. As a leader, you have to make the space for people to feel safe to go through the creative process and be in the unknown.
Martin Eriksson opened the day with a story from his time as a PM at a London startup and a release that was particularly pivotal for the product, and for the company. At that time, he questioned his contribution to the release — he hadn’t prioritised any of the stories, discussed any of the designs or done any of the code. Yet, while that release had nothing to do with him, it had everything to do with him.
He had set the vision, he had given the team space to create that release, he had put the stake in the ground and allowed the team to follow that goal. While that contribution cannot be measured in lines of code, or in pages of prototypes, it is real.
A few of the other speakers had advice on product leadership. SVPG’s Lea Hickman spoke about the importance of communication, with the team, with management and with stakeholders. A product manager at all levels needs to be able to report back, and do so in an honest way. Admitting to failure away from blame attribution will help the team grow. Even at a junior level, a PM needs to set the rules of engagement with stakeholders, and that skill will continue to be useful as you progress along your career, so will accountability and integrity.And for her the ability to create autonomous teams only came with the teams taking on accountability and integrity, else it would simply be anarchy.
You shouldn’t be more concerned with being liked, over being open.
Barrie O’Reilly, who makes a living coaching C-suite leaders came from a different angle, and suggested that a leader needs to transform themselves to allow for transformation of the organisation — else transformation is destined to fail.
As a leader you think of your customers as your external customers, yet your staff and the people in your team are equally your customers, looking for your contribution as a leader. A great leader doesn’t have great answers, they have great questions. They can set a vision, yet on the execution, they need to give their teams purpose in order to empower them.
A while ago at Product Tank London, we discussed ‘when your customer is not your user’. The speakers described their experiences of where their customer was not their user, what the challenges were and how they were (or weren’t) overcome.
When your customer is not your user…
One example of where customer != user is agencies. You are working for a client, whose users you are trying to engage. You have to please your client while creating something meaningful for their users. Depending on how familiar your client is with your process, that can be very difficult. There is a lot of client management that will require you to sometimes make compromises, and sometimes interpret what the client wants.
Another example came from a pre-AirBnB holiday letting website. The people paying for the service were the home owners wanting to rent out their place. The renters, who were the end users of the service were not paying anything. For this company, only some of their users were their customers. This led to the PM being forced to prioritise the needs of the home owners over the renters, which led to a terrible experience on the website — until they fixed it!
Another case discussed that evening was an enterprise software. While an enterprise product is used by many employees, the decision-maker on buying the software is usually the IT team or the CIO. In the past, enterprise software considered the needs of the buyer above anything else. The buyer usually wanting to lower risk and increase uniformity in process across the company. The needs of the users of being more efficient and flexible were often secondary. However, as the enterprise software market has become more competitive and mature, the needs of the user have been considered more and more. Yet balancing the buyer’s and the users’ needs remains a tough challenge for software enterprise PMs today.
Is life so much better when your customer is your user?
When the customer is your user, can you really just focus on your user’s needs, right?
Well — the story is more complicated. Whenever you have customers paying for a product, you will also have shareholders, or investors, or someone caring to create profit. Arguably, good user experience leads to more profit. But surely, you will have to prioritise certain features that help you make profit over a good user experience. For example, Instagram ads. They added nothing to the user experience, in fact they’ve made it a worst platform, yet the revenue generated for Facebook is huge. Again, as a product manager you will have to manage the fine balance between these conflicting interests even when your customer is your user.
Now, there are PMs in the non-profit sector, but they also have to worry about things other than the user needs. Often they are working in environments with small financial resources, or they have funders restricting the way their money is spent, or at least they have to align with the organisation’s overarching strategy, which may conflict at times with what the user needs are.
The good news is — that means we have a job!
Regardless of whether you are on a pure consumer product, a B2B product, in non-profit or in agency, a PM will always have to balance user needs with external pressures. They will just be different. If it was easy to determine what feature should be built next — then they probably wouldn’t need us.
It just shows how important our role as PM is. We attend long meetings to understand our stakeholders, we spend endless hours in user labs to understand the users, we are always learning about the context our products operate in and we work closely with our team to understand the technical limits. This is what allows us to then prioritise features confidently.
If it was easy, we wouldn’t be here! So be grateful for the challenge. 🙂
I decided to write a PM manifesto to hang over my desk so that I remind myself as to what is important to me in my role as product manager but also generally as a human interacting with my colleagues.
Here it goes:
1. Practice equanimity
2. ‘Yes’ is a commitment, use it wisely
3. Read twice before you send
4. Be honest and straight-forward
5. Smile (while you still got teeth)
1. Practice equanimity
I learned the word equanimity at the 2016 Mind the Product conference — and if like me, you had not come across the word before, it means ‘calmness and composure, especially in a difficult situation’. I think this skill is very useful because when people are passionate about what they do and spend a lot of time figuring out solutions to problems, when something goes wrong, it can quickly be the end of the world for them. If as PM you join the panic, that isn’t helping anyone.
I see my role as a calming force that can put things into perspective and help the members of my team to see a way out of a problem.
2. ‘Yes’ is a commitment, use it wisely
I suffer from typical people-pleaser syndrome, where I would rather say yes than no, even when I am not sure of how and whether I can do it. Therefore I try to remind myself that saying ‘yes’ is a commitment, and that I will feel terrible if I can’t deliver on it. I need to stop and think before every ‘yes’.
3. Read twice before you send
Emails, slack messages or document comments, reading them twice means that a lot of mistakes get corrected before they can cause damage. When I write too quickly, I can send a message to the wrong person, or use the wrong tone. Also, it means that I take more time to explain things succinctly, rather than type what comes into my head. By reading every message twice, I am able to reflect and be a much better communicator.
4. Be honest and straight-forward
I think, this one is an obvious one, but I’ve included it, because for me transparency is really important. Especially if I see other people play the office politics, I might be tempted to do the same. This is to remind myself, that this isn’t me, and that I want to treat people the same way I want them to treat me. And I would rather hear a hard truth, than some nice bullsh**.
5. Smile (while you still got teeth)
I think a positive attitude is always helpful to get you through the day — and it creates much better relationships with your colleagues. That way you can tackle a difficult problem with a friendly discussion, rather than get shouty before even getting to the solution. A smile tends to also disarm people in an ego-war. 🙂
I want to share a framework that I created to review the customer experience of my product, as I started in a new role. I hope that it offers you an opportunity to review the customer experience for your product, whether you’re starting out or if you’ve been on a product for a while. I see this framework as particularly relevant if your product is part of a product suite. You might have a Marketing or Customer Experience team, yet they will be interested in the customer experience overall and not necessarily look at how your product fits into it.
1. Product Marketing
The Marketing department is brilliant at what they do, however, as PM you know your product best. The Marketing team doesn’t have the time to understand the ins and outs of your product and will need you to come to them to help your product’s web page or campaign. You should regularly review the first point of contact that potential clients have with your product online, be it on your website, your social media or online ads. You need to be the external and internal advocate for your product. Make sure your product’s name is consistent in the product and on your online marketing channels — this may seem obvious but you’d be surprised. Make sure the proposition of your product is clear — and that also the most relevant features are advertised without creating false expectations.
2. Your product in the trial journey
If like many Saas companies, yours offers a free trial, it is important for you to review the role your product plays in the journey. The trial is a sort of wooing period to convince trialists to convert to paying customers. The art of the trial is to get potential customers to understand your product and see its value to their lives without bombarding them with too much information. Sign up for the trial to see how potential customers will interact with your product. Is the essential value coming across, are customers encouraged to try your product? Can you track whether they actually try it out? You’d be surprised at the flaws you may discover here.
3. The Sales team needs you
If your company uses Sales people for their larger deals, they can be one of your most important allies. It’s good to work hand in hand with them, by giving them extensive training, guides, 1-pagers and videos so that they can effectively and truthfully depict what your product does. Let’s face it, if there’s gaps in their knowledge, they might start to fill them with what they would like the product to do!
They are also your eyes and ears when you are busy prioritising the backlog and engaging in discussions with design and engineering. The input from the Sales team will help you build an effective roadmap. They can also enable you to meet your customers face-to-face. The Sales team will know exactly what will make or break a deal. While not all they say should be taken for gospel, speaking to your sales team will keep you grounded.
4. Track and review commitments made during sales
When large sales deals are made, it is likely that your sales team will commit to certain features being built. This would generally require your input and agreement. Yet if you’ve just started, you’ll have to catch up as to what the intention of each request is. The customer success managers or account managers will make sure you’re on track with customer commitments. The challenge here is to address these requests while also building a strategic roadmap that isn’t a list of random features each required by a different customer. Following only feature requests from customers will at worst create an unusable product, and at best a highly complicated product with two levels of advanced settings.
I know that this can be challenging, especially if some of your customers represent large deals and there is pressure on you to make them happy.
The best thing is to work with the Sales team to get customers to commit to certain features, which are already on your roadmap. Get them excited about upcoming features and ensure that any new commitment fits into the overarching strategy of your product.
5. Identify your important customers
These aren’t necessarily the largest deals for your company but rather the super-users of your particular product. They are the ones who wouldn’t want to go without it. Identify who they are, who their contact in the company is and foster a good relationship with them. Make sure they know how to reach you and understand your roadmap. If possible, arrange to meet your super-users in person so as to get their input first-hand. Their feature requests will be well-informed and a close relationship with them will help you build a better product. They might give you feedback on early designs and be a good sounding board for new ideas.
6. Have clear insights into your product
Analytics. Analytics. Analytics. You need them, but don’t overdo it. There is plenty of advice out there to track MAU, DAU, or better ARPMAU and ARPDAU. However, what is key is to understand what matters for your product. This may not be the same for other products on the same platform as yours. For me, I have found mapping the user journey across the different products and on my product, helped to define what metrics really mattered.
I am continuously learning and improving the data I use to measure product success. I found it useful to define between 3–5 different variables, which I can track over time and communicate to the rest of the company. The biggest struggle was defining active users, and what tools to use to measure their activity. This quantitative data will complement what your users are telling you directly and help you understand the bigger picture and support the features on your roadmap.
7. Inform your customers, don’t spam them
Another skill is to keep your users informed of new updates that can solve their problems, without sending too many emails or constantly nudging them inside your product, especially if there are several product managers competing for user communications. Select the main features and find ways to bundle new ones together. If you can, give the user value update — e.g. ‘here’s how sharing has been improved across mobile, web and desktop’.
Striking that balance is an art, and the user engagement team will be a good advisor in this case, as they will often channel all communication — depending on the size of your company.
8. Inform your colleagues, don’t spam them
Don’t forget about your internal users — especially the customer facing teams: Support, Marketing, Customer Success as well as other Product Managers. They need training on new features your team develops. Believe me, they hate finding out about a new feature from a complaining customer.
There’s however a difficult balance to strike here between under-communicating and over-communicating. If you describe every push notification and transition you’ve been working on, people will quickly switch off. That’s why you need to communicate to them in terms of the value the feature brings, whenever possible, share a screenshot or recording so that they can visualise it.
9. Know the industry.
Being aware of product developments in the industry is important to stay competitive. Your sales team will offer great insights into what your customers like in other products. This will help you appreciate a competitor’s feature that on the outside may not seem like a major innovation but solves a critical problem.
Use Twitter as a news curation website, attend industry events (live-stream big conferences — Google, Microsoft or Apple events) and sign up to your competitors’ and bloggers’ newsletters so that the information will come to you. It is easy to stop paying attention to the industry when your team needs your attention. However, it is key to stay on top and understand the latest trends, because this is what separates the good from the great.
I hope this framework has got you thinking about the customer experience of your product and helped you identify whether there’s anything you can improve. I still go back to this framework every now and then to check whether I am doing the right things.
In user experience, how long is a button press is the new ‘how long is a piece of string’. You need to know what you need the string (button) for before determining how long it needs to be.
The time I am particularly interested in looking at is:
the time between the user clicking/ tapping on an area and the moment the intended result appears, including loading states.
I have found that this time is directly related to the trust a user places in the action.
Example 1: A restaurant-finding website
A user selects certain search criteria, clicks search. Within less than a second the website would directly show thousands of results. The engineers had worked really hard to get it to work this fast, they were proud of their work. However, in user testing, the team found that people didn’t trust the results they were shown. How can a website find so many results on the internet that quickly. Surely there was some fakery going on. Luckily the team listened to the user testing and added a fake loading state to indicate to their user that their engine was crawling the websites and doing a really rigorous job to find the absolute best price for the user.
Example 2: A document comparison software
The user selects two documents and hits ‘compare’. A loading bar would appear until the documents were fully compared. If the document was complex and long — and somehow people who use comparison software generally have complex and long documents — the comparison would take a long time, sometimes over a minute. Again the time it took to compare did not align with the users’ expectations. They would start to mistrust a comparison that took too long. They felt the software had frozen and was struggling to produce the right results. This gave the engineers extra motivation to make the comparison engine run faster.
It seems that the users’ trust is very dependent on their expectation of time, anything slower or faster will start to look fake or unreliable. I was wondering where these expectations come from — because who actually knows how long a crawler takes? I believe that all of the digital experiences users have, be it on their phone or at a ticket machine build a sort of understanding of how quickly a computer can process, and as we become accustomed to different pieces of tech, our expectations evolve. Which means that our products have to evolve with them.
For me, this points to two key ideas:
User testing is crucial — it’s not always about making transitions faster, but about meeting the user’s expectation of speed. Only user testing will confront you with real results.
Your product is not only competing with direct competitors. The user’s expectations of speed come from their daily interaction with apps, websites and tools completely unrelated to your product.
Here’s some of the questions I get asked by people interested in product management.
What is a Product Manager?
In a nutshell, a Product Manager oversees a team of engineers, designers and testers to develop a product, bring it to market and grow it. A Product Manager sits at the interface between design, engineering and business without the need to be an expert in each of the areas. The strength of a Product Manager is having an in-depth understanding of what the customer wants, communicating frequently and gaining feedback, testing prototypes and bringing that customer need back to the team — in order to work with them to create a product that fulfils all criteria. Simple, huh!
What skills does a Product Manager require?
In terms of hard skills, an engineering or a design background can be an advantage, so are data science and SQL skills, but you’ll find many Product Managers who don’t have such technical background. The single most important skill that a Product Manager should develop is influence. While none of the people on your team report to you from a management perspective — you can’t fire them or affect their pay — your ability to win people over, to pitch ideas and to use evidence to construct convincing arguments are your most valuable assets. With experience, you can learn the capacities and limitations of the technology as well as best practices in UX and UI design. Your interpersonal skills will also come in handy in your communication with customers — from identifying a new need for a product feature to translating it in a technical business requirement in your teams. Empathy is your greatest asset here.
What experience is useful to become a PM?
Looking at my peers, I have found people from such diverse backgrounds, which confirms it for me that there is no clear route into Product Management. You can start in a specific role in the Tech sector, you can be in project management or you could be an engineer and realize that you would like to try Product Management. A common route is also that of a Business Analyst.
How can you find out more about Product Management?
The advantage of Product Management being a fairly new field means that a lot of experts are offering definitions of the discipline, which is still being shaped. If you’re interested in finding out more about Product Management, this is my ultimate list:
If you really like reading, then you might find Facebook PM Simon Cross’s reading list useful.
If, like me, you have a fairly short attention span, then you may prefer podcasts or blogs, such as SVPG’s.
If you prefer newsletters that will come into your inbox once a week, great reads I enjoy are Ken Norton’s Bringing the Donuts, and Mind the Product.
Mind the Product also organizes events, there’s the conference, which comes at a price, but also free monthly events called Product Tank where they tackle different topics relating to Product Management, plus it’s a fantastic networking opportunity. ProductTanks get booked up quickly, so make sure to sign up as soon as you see it.
What’s so great about being a Product Manager?
What I love about being a Product Manager is the challenge of solving problems, of getting people rallied around a problem and of juggling multiple priorities. I get to interact with all parts of the business and it gives me a great insight into how the business is run. While not a creative role in the strictest sense, creativity is key when it comes to addressing challenges, often with limited resources.
I read Marty Cagan’s article on why women make the best Product Managers with utmost interest. I agree that to some extent the qualities society rewards in women are beneficial to the role of Product Manager — such as emotional intelligence and humility. On the other hand, qualities associated with masculinity may be not be as beneficial. However I have a separate argument as to why he found such outstanding female PMs — that of ‘natural selection’.
The female PMs Marty has met are in fact better than average because they have had to face more adversity than their male counterparts. And in that sense, I think this argument also applies to PMs of ethnic minorities.
Structural barriers against under-represented minorities and women mean that they get promoted and hired less in an industry dominated by white men. It means that non-white and non-male PMs will probably have to compensate , by being extra-persuasive, extra-knowledgeable and extra-skilled than her male white counterparts.
It relates to the stories told by Malcolm Gladwell in his book ‘David and Goliath’, where major disadvantages force underdogs to find workarounds and get better at specific aspects so that they not only make it but exceed all expectations. The adversity experienced by non-white non-male PMs means that they have had to work harder and better than their white male counterparts. They have been naturally selected for being tenacious, experts at leading with influence and always ready to do the legwork — all skills hugely important to the role of Product Manager.
The day after MTPcon I wrote down a list of things I want to do or do differently after hearing all these inspirational presentations. However, it’s been three weeks and I have done exactly none of them.
Here is my list:
1 Regroup with the members of my team individually to understand whether the way we work gives them sufficient psychological safety and try to understand if there is anything we should do differently as a team.
2 Think about the story of my product. Donna Lichaw’s presentation was really interesting but I struggle to see what the story of my product is. Need to book in some time to think it through.
3 Read — from the many book recommendations, start with Thunder Below and work my way down the list shared by Simon Cross.
4 Create an internal equanimity check: when there is a crisis, people at work tend to dramatise —often to highlight the importance of said crisis. But even if I try not to get caught up in that, I feel I need a better technique to calmly reflect on the situation.
5 Make sure to formalise convergent and divergent thinking during team meetings.
6 Never cover up my mistakes and make sure to explicitly own up to them.
7 Schedule a call with a customer.
8 Review our international distribution and engagement rates and see if we could improve the product by tailoring it for specific audiences.
9 Celebrate success with my remote team.
Here are the excuses I came up with for not doing anything about them:
I‘m too busy
The team is remote and it will never work
Clearly I had plenty of good intentions but my original resolutions were too vague and there were too many. So what I’m going to do now is to focus on the top three things I think are most important and make sure I implement them and also make them more concrete so I can actually do them:
Buy Thunder Below online and add it to my reading shelf
Book a call with each of my team to just get a feel of how they see our team work, whether they need anything and whether we could improve our collaboration processes.
Write my PM manifesto. This is something I heard on the Happier podcast. Gretchen and Liz recommend to write a manifesto to distill the principles you want to live by — this can be for your job, for your relationship, for your family or just for yourself.
Digital Good 