Back in 2012, Spotify released a whitepaper talking about how they scaled their company. One of the ideas that they introduced was a community of practice called a guild. Here’s how they describe it:

A Guild is an organic and wide-reaching “community of interest”, a group of people who want to share knowledge, tools, code, and practices.

(Of course, Spotify don’t have a monopoly on the guild concept, for example, here’s how Hootsuite describe their take.)

Inspired by Spotify, Trade Me’s Product Management Guild kicked off in early 2015. It is made up of all of Trade Me’s product managers (about 22 at the time of writing) and our primary touchpoint is a three-hour in-person meeting once a month where we share knowledge, tools, and practices. Topics include things like:

• Downloads from conferences and workshops like Mind the Product, Leading the Product, WWDC and Google IO
• ‘Lessons learnt’ case studies on products we’ve built (e.g. shipping), or approaches or experiments we’ve tried (e.g. metrics-driven development)
• General tech trends e.g. how Kiwis use their mobile phones, social media usage
• General information sharing sessions from other parts of Trade Me like Platform and Operations, Marketing, Legal or UX
• Discussions on our tools (e.g. tips on roadmapping) and processes (e.g. how to best capture ideas)
• Zippy WIP — a fast, round the table, ‘what are you working on?’

Every 6 months or so we run an offsite too, where we spend the whole day together to go a bit deeper, both in terms of the relationship and how we do product management.

Unlike some of the other guilds at Trade Me, and the original definition from Spotify, ours is an invite-only group — essentially if you work at Trade Me and have ‘Head of Product’ or ‘Product manager’ somewhere in your title you are expected to be part of the product management guild, and if you don’t then you can’t just turn up uninvited.

We also have a charter that describes the behaviour we expect of one another. It looks like this:

As product managers at Trade Me, we agree to:

1. Communicate well

We communicate frequently and clearly with one another, with our squads, with our colleagues from across Trade Me, and with our users.

2. Help one another

We seek and provide input and advice on new ideas, initiatives and projects. We actively listen, we respond in a timely way, we share knowledge, we engage. We want to learn from one another.

3. Constructively challenge

We deliver candid and constructive feedback and we strive for specifics — describing what is wrong, what is missing, what isn’t clear, or what doesn’t make sense. As a group we demand well-considered product decisions, even when those decisions don’t directly impact the products we are responsible for.

4. Put users first

Our aim is to improve the lives of people who use the products we build. We strive to deliver stable, elegant, innovative products that deliver more than our users ask for. We are advocates for our users and act with them in mind, whether it be developing new features or acting fast when things go wrong.

5. Innovate

We build with the future in mind. We experiment and take risks, we iterate fast and well, we accept failure is a by-product of the innovation process. We consider day-to-day business-as-usual alongside 10x bets on the future of the company.

6. Be openly professional

We are a passionate and engaged team, success-driven and quality-focused. We pursue alternate viewpoints. We are transparent in our communication and reasoning. We prove the value of product management through the work we do, and we inspire those around us. We are never dismissive. We aren’t dicks and don’t tolerate those that are.

Best practices and tips and tricks

Here are a things that we would recommend if you wanted to set up a guild:

• Think carefully about the frequency of meetings — err on the side of more frequent to begin with, and adjust over time. We started off by alternating informal ‘drop-in’ style sessions with more formal, compulsory sessions but ended up dropping the ad hoc sessions when the attendance dropped off.
• Begin with a retrospective and use the pain points as a starting point for topics. I think guilds work best when they aren’t just about talking, but when there is some aspect of doing, and what better thing to ‘do’ than fix the things that aren’t working well?
• Take good notes. We write up minutes of our meetings on the company wiki, for all to see. It acts as a handy place to drop slides, and if anyone misses a session then they can peruse the previous 33 meetings at their leisure (it’s great for new PMs too!)
• Get out of the building. Some of the more memorable, brain-stretching guild sessions have been when we’ve visited Air New Zealand or the Police Innovation Centre, gone to our national museum (handily, just across the road from the office), or taken an all-electric car for a spin.
• Encourage culture of self-governance. It started out with me as Chief Product Officer organising the guild, but these days we have rotating hosts who help curate, coordinate, and administrate the guild. This makes the guild resilient — it doesn’t fall apart as soon as someone is sick, on holiday or leaves.
• Invite non-Product Managers to speak. We often invite internal people to speak to us on a wide variety of topics: what claims we can make from a legal point of view, Elastic Search functionality or third-party usage of our API. We’ve only had external people a couple of times, from Lightbox and PwC Digital, but we should do that more.
• Encourage continuous improvement. Our last session we had our first themed meeting, all about pricing. We’ve recently extended the in-person session from two hours to three. A few months ago we agreed to invite mentees to our sessions. We are tweaking things all the time.
• Do a Zippy WIP. People discussing what they are working on can be pretty dull if it’s not something that intersects with your own work. So we do what we call a Zippy WIP (WIP = Work-in-progress) — the idea is that the update is short and it is perfectly acceptable to not give an update at all. Our product managers find this really useful, in order to better understand how to leverage one another’s experience.

Good product managers take stewardship of their craft seriously. We’ve found that providing a space to talk shop, through a vibrant healthy guild has been a great way to grow the product management practice at Trade Me.

8 tips for running a great product management guild was originally published in Trade Me Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

In general

• Help the reader understand how the work is prioritised. For example, if the one-pager is about introducing a new premium product, explain why it is that we aren’t instead focusing on the premiums we already have — improving the sell process, ensuring we have parity across all platforms, etc.
• Write in plain English. Ensure that the one-pager flows well and tells a coherent story. It can be helpful to read it aloud, end-to-end.
• Be consistent. For example, don’t say the product is for ‘all buyers and sellers’, in the solution statement and then ‘casual and semi-professional sellers’ in the Elevator Pitch.
• Make sure that the one-pager title is descriptive. The whole point of one-pagers is to help communicate, and using titles like ‘Hustler’, ‘The Force Awakens’ or ‘Phoenix’, or even really generic statements like ‘Search fixes’, make it harder to tell at a glance what the one-pager is about. If you do decide to use a project name, includeit alongside a more descriptive title e.g. ‘Motorweb Industry Site Redesign (Project Phoenix)’.
• Use screenshots. Product managers know their stuff inside and out, but often the readers and reviewers are less familiar with the specifics. Personally, I find I’m rustiest on our pro seller tools like Tradevine and Dealerbase. Screenshots can remind readers of the context and clarify what you are proposing.

Problem

• Make sure you provide an adequate fact base. Make it super clear what we know rather than what we think, and you’ll have your reader nodding all the way through your problem description.
• When quoting research, link to the source.
• When using qualitative research, quote the number of participants. I have seen one-pagers that say ‘75% of respondents indicated they would create a profile’, when n= 16. When dealing with small numbers of participants, it’s often to better to avoid percentages or ratios altogether and instead say ‘12 of 16 respondents indicated they would create a profile’.
• Ensure that the research is relevant. If it comes from overseas, then at least try and normalise it for the New Zealand context. For example, ‘two-thirds of vendors in Australia have told us that one of the most stressful parts of the selling journey is choosing an agent.’ That’s interesting and potentially useful, but how do we know it’s true for New Zealand?
• Don’t mix in solutions alongside the problem. We have a whole separate section for describing the fixes to the problem!

Solution

• Don’t use the word MVP, unless it is. Here’s why.

Who’s it for

• Be specific. Statements like ‘regular visitors’ is too broad, something like ‘Job seekers who visit Trade Me and view at least one job’ might be more appropriate. Ideally, you’d quote the specific personas that the work is targeted at.
• Ideally, state the actual number of users impacted by the work.

Costs

• Don’t make readers do the maths — add up the total amount so people can see it at a glance.
• Make sure you include external, third-party costs as well as squad time.

Inform

• Name individuals, rather than entire teams. Often ‘Legal’ will be listed as a Consult, but they never get notified about the change because there is no concept of ‘mentioning’ an entire team in Confluence (our wiki software). If you mention individuals, they will receive a notification.

Success criteria

• Show your working. How did you come up with the target number? What assumptions have you built in?
• Ensure that the success criteria clearly link back to the Hypothesis.
• Sense check the ROI. ‘OK, this is going to cost us $72K and our success criteria show that within 3 months of the launch we’ll have only 740 reports created….hmmm.’
• Make sure your targets are realistic. This is the flipside to the bullet point above — make sure you aren’t overly optimistic and unrealistic. It defeats the purpose of the one-pager if you game the numbers.
• For projects costing $1m+, do a more thorough investigation into the payback. I once wrote this in a one-pager: ‘The return is positive (Discounted cashflow at 20% returns a NPV of between from $135K and $1.26m), but isn’t stellar, and we have to wait 4 years for the return.’ You won’t get into this level of detail every time, but bigger projects ought to have a higher bar.
• Be specific about when the success criteria will be hit. Will your numbers be hit on launch? A month in? Three months in?
• Follow the guidelines for using the HEARRRT model. In particular, make sure that the metrics are sensitive to product changes (in other words, easy to prove). For example, we often see an increase in Net Promoter Score as a success metric but it’s rare that any one feature makes a measurable difference to overall NPS.

So, there you have it. A few random ideas to help improve your one-pagers. What tips do you have?

23 tips for writing great one-pagers was originally published in Trade Me Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

It went through an overhaul in early 2015, and nowadays it’s an easy-to-create template on our wiki:

Why one-pagers?

Trade Me is a complex, fast-moving business. While we need to move quickly to respond to our users and the market, we also need to ensure we’re working on the right things at the right time with our limited resources.

A one-pager is a quick and consistent way to summarise what we are working on in plain English, and ensure that everyone who needs to be involved has had a chance to input.

It encourages the tough questions to be asked and trade-off decisions to be made early. It also indicates that a new piece of work is starting, so we can spot crossovers and dependencies between different areas of the business.

Perhaps most importantly, the one-pager forces us to articulate what success looks like in the form of concrete, measurable metrics.

Finally, having all the one-pagers on our wiki has a bunch of benefits — everyone across the business can read and comment on them, it acts as a form of organisational memory, and it is a great way for new product managers to come up to speed quickly, by perusing the 175 one-pagers in the library.

There are seven key parts to the one-pager

1. Hypothesis

This is a simple, scene-setting sentence that summarises the work in the form “we’ll do X and we think it will have a impact Y.”

2. The Problem

This is where most of our thinking and work is done. As a guide, we try and spend twice as much effort here compared to “The Approach / Big Idea” section.

The problem statement should include data, facts, assumptions, analysis, tables, graphs — an evidence base that clearly articulates what the issue is and how it is affecting Trade Me or our members.

3. The Approach / Big Idea

These are our early ideas on how to solve the problem and as such they shouldn’t be too prescriptive — the exact solution should be defined together with the squad.

This is also the place to record best practice, patterns, comparative and competitor reviews, known gaps, what’s out of scope, Trade Me’s competitive advantage, dependencies, etc.

4. Elevator Pitch

This is our snappy, user-focused answer to “what are you working on”? An elevator pitch has the following format:

FOR <target customer> WHO HAVE <a customer need>, <initiative name> IS A <thing>THAT <one key benefit>.

UNLIKE <competitors>, OUR PRODUCT <unique differentiator>.

(To be honest, we could probably kill this section and not lose anything. It can end up being a bit of a contrived statement.)

5. Success

This is where we state the likely user and/or business benefits for the project, based on the HEARRRT framework.

6. Who’s it for?

Our UX team have done a dozen in-depth research studies to understand our users that they’ve documented in the form of personas, and each one-pager should explicitly name the personas that the project or feature is aimed at.

7. Who’s Involved?

This is where we make sure that others from around the business are across the work. We use a homegrown decision-making framework to help, that we call V-CARDI:

• Veto
• Consult
• Action
• Recommend
• Decide
• Inform

The beauty of the one-pager on the wiki is that we can easily ‘tag in’ all these people, and they get an automatic notification that their name has been mentioned.

The product manager authors the one-pager, which is then reviewed by our Product Council

Typically, a Product Manager writes the one-pager, with help from fellow product managers, squad members, analytics, legal, finance, comms, etc for input and review.

We write a one-pager for every piece of work that is more than one month of effort (regardless of elapsed time) or that is strategic in nature.

Once it’s finished, the one-pager gets reviewed by our Product Council who:

• ensure we’re following our product management processes
• question our product priorities, and how this work fits into the bigger picture
• help identify co-development and co-operation on similar product initiatives

Summary

A well-written one-pager is a thing of beauty. It’s succinct, simply communicates an idea so that anyone across the business can understand it, and forces us to properly think through why we are building what we are building.

Stay tuned for Part 2 where I’ll go into a bit more detail and give some tips and tricks for writing one-pagers.

P.S. For the most part, our one-pagers are our mash-up of others’ ideas. The lean canvas approach, the elevator pitch, even things like the RACI decision-making framework have either acted as inspiration, or been straight out copied. We owe a debt of gratitude — thanks!

An introduction to Trade Me’s ‘one-pagers’ was originally published in Trade Me Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

This felt like a daunting task, until I realised that lots of others had been here before, especially in the start-up space. So, stealing the best from the metrics for pirates and Google’s HEART model [PDF], I created a shameless mash-up called HEARRRT. It looks like this:

The HEARRRT model is essentially designed to tease out and stimulate ideas for measuring product success. Each letter stands for a different category of metric:

• Happiness: A measure of user satisfaction and / or success. This can be attitudinal or behavioural.
• Engagement: The level of user involvement, typically measured via behavioural proxies such as frequency, intensity, or depth of interaction over some time period.
• Audience: The number of people coming to the site or app from various channels.
• Retention: The rate at which existing users are returning.
• Referral: Whether users tell others about their Trade Me experience.
• Revenue: Goals that relate to users paying us somehow.
• Tech: Improve the way we do things ‘under the hood’.

Here’s how you use it:

1. It starts with choosing which of the HEARRRT categories to focus on. Usually this is pretty easy — is the feature or product designed to improve customer satisfaction (H)? Or make more money (R)? Or reduce tech debt (T)? Sometimes you might choose more than one of the letters.
2. Next, you move from left to right and select a “higher-level goal” we are trying to achieve. After all, we should be choosing metrics that help us measure progress towards our overall business priorities.
3. Then, you brainstorm all the potential ‘signals’ that indicate whether we are making progress towards the goal. This might be things like NPS or referrals or traffic or load time.
4. Finally, we choose one or two of the signals and set a target value we want to hit.

This last step is the trickiest bit. The final product success metrics should be:

• Small in number. You can’t expect every number to go up-and-to-the-right, so it’s important to focus on the two or three things that you care about above all the others.
• Realistic. This is one of the hardest ones to get right. How do you know how many report views to aim for, if you’ve never built an insights product before? One idea is to use what data you do have. For example, you might be able to estimate the proportion of visitors who will be interested in downloading a report. Or, you could set a target based on the cost of the project. For example, if the cost of the project divided by the number of reports downloaded means that each report costs $100 then maybe the target is too soft (or you shouldn’t build it at all!)
• Specific. There should be no wiggle room, no room for interpretation. This includes the timeframe for hitting the metric. Increase sessions by 20% — great. But by when? On launch day? Within 3 months?
• Easy to measure. I’ve often seen things like Net Promoter Score as a success metric, only to find out afterwards that NPS is something which we only ask for every six months. Your success metric is ideally something that’s at your fingertips.
• Sensitive to product changes (in other words, easy to prove). If we say a project’s success measure is to increase sold items by 2%, it’s important to have clear line-of-sight between the product change and the increase in sold items. If we can’t hand-on-heart say that a number moved up or down because of a product change we made, then it’s not a good metric.
• Related to a business goal. Finally, it always pays to do a final sense check to make sure there is a clear link back to the overall business goal too.

One final point — getting better at writing success criteria requires a feedback loop. That’s why we insist on the Product Performance Report, because it’s in reporting back on actual product performance that you realise that your metrics were unrealistic, or didn’t specify a date, or that you can’t accurately measure a change.

HEARRRT — Trade Me’s metrics framework was originally published in Trade Me Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

What is an MVP, then?

The term MVP was popularised in 2009 by Steve Blank and Eric Reis, as part of the lean start-up movement. It’s defined as “that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.” (If you are super keen, watch this 5-minute video).

An MVP doesn’t have to have any connection to the finished product. In fact, it doesn’t even need to involve code. As Steve Blank says: “You’re not building a product...you are trying to elicit responses from customers.”

So, what can we do improve our MVPs? Three things:

1. Document your assumptions

Minimum Viable Products are all about “maximising learning”, so it makes sense to start by identifying your assumptions. It can be helpful to phrase them as hypotheses: “We believe that _________.”

2. Decide what metric you need to validate your assumptions

How do we know that advertisers want to buy native ads? How do we know that agents want to promote themselves? How do we know that members want richer shipping options? It can be helpful to extend the hypothesis statement: “We believe that _________. We’ll know this is true when we see _________.”

3. Identify the Minimum Viable Experiment, ideally involving minimal or no code, that you could do to validate your assumptions

We need to deeply understand users via usage data, surveys, in-person visits and anything else that can help us fill in the blanks. We should be prototyping our ideas, and showing users mockups long before a line of code is written.

Finally, if you remember one thing about MVPs, let it be this: Minimum Viable Products are all about “maximising learning.” And the most effective way of maximising learning, and our insurance against wasting effort on things that aren’t going to work, are well-run experiments. In fact, I think a lot of the confusion with the term MVP is the word ‘product’ and we’d be well served by changing the name to Minimum Viable Experiments instead. Calling them MVEs will more effectively remind us that we need to test and validate our ideas, and experiment often and well.

I’d love to hear what you think!

The MVP is dead, long live the MVE! was originally published in Trade Me Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

One of the best books I’ve read on the topic is called The Leadership Challenge. Since 1982, the two authors of the book have asked people all over the world the same question: What values, personal traits or characteristics do you look for and admire in a leader?

Over 30+ years the data has been strikingly consistent across decades, genders, different types of organisations, and ages. The four most important characteristics of admired leaders is that they are honest, competent, forward-looking and inspiring. (If you’re interested, here is a TEDx talk on the topic.)

Hopefully most product managers are honest and competent. But being forward-looking and inspiring, those are much harder than the first two. In fact, in the book, they state that “expressing a vision is the most difficult of all the leadership skills”.

And because ‘practice makes perfect’, every three months we ask our Heads of Product to re-articulate their product vision.

It’s funny, you would think the product vision wouldn’t change over such a short timeframe. But every time, the vision seems to get a little bit clearer, and a little more inspiring. Sometimes it’s just a single word that changes, like the Marketplace strategic roadmap review yesterday. (I think this is a really healthy sign: product managers should sweat every single word in a vision statement. Every word ought to fight for its right to belong.) And the good thing is that every time we pick up a vision statement, turn it around and look at it from every angle, it seems that the “most difficult leadership skill” gets a little easier.

Great product leaders have great vision was originally published in Trade Me Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Fast forward 10 months, and I had accepted the role as Trade Me’s first-ever Chief Product Officer. One of the reasons I said yes was that Jon assured me that the role did come with authority, or ‘teeth’ as he put it, and would represent him for all things product-related.

Within two months of arriving, based on what came out of an offsite with our 10 product managers, we made a bunch of quick-fire changes to our tools and processes. But then I really freaked everyone out and wrote this:

It’s one thing that we have these tools and processes, but how do we make sure that they are used correctly? Who are you accountable to in regards to following a robust process? I recommend that we establish a Product Council to provide a level of oversight, and ultimately ensure we choose the right products to build.

I proposed that the council do two things: review one-pagers (our version of a lightweight business case), and review the product managers’ roadmaps.

Partly because I deliberately and liberally used words like ‘governance’, and ‘process’ and ‘rigour’, I got some push back from the product managers, who said things like:

• It seems like a lot of process
• I read your email and thought, whoa, admin overhead just ballooned, slowing me down in a big way
• I’m surprised by the lack of product experience on the Council. If the Council is about making sure that we do product management better then it seems weird that it doesn’t include product managers
• The way you’ve described the 30-Day session sounds quite confrontational
• I feel this extreme level of an exec oversight committee is the antithesis of innovation (or intrapreneurship)

and my favourite:

• It absolutely assures only safe, pedestrian “sure bet cookie cutter” ideas get any traction as no one wants to convince their squad, their manager, their business owner, the chief product officer, the head of design, the head of tech of an idea to get it moving, then defend said idea every 30 days all the while following somewhat arbitrary processes that a generic enough to apply everywhere. You’ve been very vocal in wanting to be wow’ed before, but this path assuredly means that’s not a possibility internally any longer

Despite these concerns, I was confident that this was the right call. The Council construct allows me to delegate my ‘teeth’ to a nimble team of three product-minded, systems thinkers who bring different experiences to bear. The three of us ask different questions, notice different things, and do a better job of supporting our product managers than any one of us would alone.

(We even hold one another to account. Earlier in the week, Simon and Ruth took me aside to host what we jokingly called an intervention, when I had made a poorly thought through decision.)

Since those early days, the upset from product managers has now faded away, and the Council is an accepted part of our product management practice. We are still tweaking how it works (two notable changes are that we no longer sign off on one-pagers, and every third roadmap review is a strategic version), but it’s stayed very true to it’s original intent and form.

What do you think, how would you improve the Council?

The History of Trade Me’s Product Council was originally published in Trade Me Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

1. Decide on 2–4 primary ‘Benefits’ that you want from each of your product initiatives. These should be driven from strategy, and might include things like Increase FY18 Revenue or Improve Customer Satisfaction.
2. Decide on 1–3 primary ‘Costs’ such as Time to Implement, Cost to Implement, and Risk.
3. Next you’ll most likely want to weigh your criteria, which allow you to place more importance on some Benefits and Costs. For example, if Improve Customer Satisfaction is twice as important as Increase FY18 Revenue, you’ll want to double the weighting of the satisfaction criteria. (At Trade Me, we use Product Plan to help with the scoring, but you can just as easily use a dirty old spreadsheet).
4. Do a preliminary scoring of each initiative against the Benefits and Costs using the scale of 1–5. (You can, of course, use any range you like, but I find 1–5 is about the right fidelity). These initial scores are your best guess and will change as you socialize your priorities. (Trust me.)
5. Calculate the totals (remember that costs are negative), and rank the initiatives from top to bottom. (BTW, you’ll very rarely be implementing them in the same order as the ranking. You might not have enough time before a brown-out to implement a feature. Or you may want to ensure you are balancing customer requests with addressing tech debt. Or a key person is away for 6 weeks.)
6. Now that you have a preliminary set of product priorities, you have something to talk about. Use this rough draft as a discussion tool with your stakeholders. Go to your key salespeople, marketers, developers, customer support, partners, customers, finance people and other product people, show them your preliminary priorities and ask for their help. How would THEY score some of these items? Which ones do they care about most? Which ones seem overrated to them? Go through them one at a time, as large groups will quickly devolve into arguments. Adjust the scores as you learn. Add additional Benefits or Cost criteria if you think you left something fundamental out. Keep socializing and tweaking until you have everyone nodding their heads or disagreeing on only a few key items.

See, easy! You can even plot it on a 4x4 quadrant:

It’s easy, but not simple.

There are two main issues I see with this approach.

Firstly, we don’t even do this much. Maybe we think a group exercise of dot voting on ideas is good enough. Or we feel like our strategy is set in stone and the features and improvements that come out of it aren’t changeable. This is lazy product management. We are oftentimes placing million dollar bets with these calls, and we need to have more rigour.

Secondly, we rely on pseudo-science. You can create a scoring guide to help you compare like-for-like. For example, saying that Increase FY18 revenue scores a 0 for $0, a 1 for $0-$100K, 2 for $101-$200K, etc. But even this is a guess. How do we know what revenue will come in? This is the hard bit.

But there are lots of different ways that we can try and more concretely and accurately quantify our scores. Use the Kano model or Buy a feature or Opportunity scoring to better understand what customers value. If you have a criteria relating to usage, then run some SQL queries to understand what features most people are using most of the time. If it’s adoption, then you might want to use choice modelling to understand what people would pay for the ‘parts’ of a product. The point is that there are a million different methods for removing subjectivity from the scoring. (Not that there isn’t a role for gut, but that’s a whole other post).

What do you think? How do you prioritize?

Product prioritization is simple, but not easy was originally published in Trade Me Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

But, the issue isn’t with the meetings themselves. The issue is how they are run.

You see, well-run meetings can be a thing of beauty. Some of my favourite times at work are, gasp, at meetings. Product management guild sessions. Weekly exec meetings. 30-day sessions.

As product managers, we spend a lot of time in meetings. In fact, I often tell people that, for me at least, meetings are the job. Product managers should treat running effective meetings as a skill to get better at. So, I have collected a few tips and tricks on running meetings that might be a good memory jog.

If you are running a meeting:

1. First and foremost, identify your objective. What must be accomplished by the end of the meeting that couldn’t be accomplished without bringing these people together?
2. Use this objective to create an agenda. This doesn’t have to be over-engineered, a series of bulletpoints will do.
3. Depending on the type of meeting, you might want to estimate an amount of time for each agenda item. Having a limited amount of time will help everyone stay on topic.
4. Always bring together the smallest number of people, based on the objective and agenda. When you run a meeting, approach your responsibility as if you are being handed a portion of someone’s life.
5. Send out the objective and agenda beforehand, ideally as part of the meeting invite, but with plenty of time for attendees to digest.
6. Control lateness. One of our Property squads does this by placing a tick next to someone’s name if they turn up late to a stand-up. Five ticks = morning tea for the squad. I will often say as a joke that latecomers owe me a $1 for every minute they are late, which is my way of making it clear that I’m not cool with it. (Andreessen Horowitz actually do this for real, except it’s $10 per minute).
7. Run the meeting from the agenda. Sometimes I bring along my TimeTimer to keep people to time — mostly when it’s a large group where there are lots of “talkers” or people with strong opinions.
8. Make sure you capture the actions from the meeting, and communicate those actions afterwards. Oftentimes I’ll use our wiki to record what took place, and to assign actions.
9. Sometimes, it can be useful to start a meeting with the Rules of Engagement. This is usually only necessary when it’s a large group discussion, in which case I usually run the meeting differentlyanyway (for example, getting people to break into small groups). However, making a few things explcit, like ‘Silence = consent”, can make things more efficient. Of course, you can always use Robert’s Rules of Order ;-P

If you are attending a meeting:

• Ask for the agenda of each meeting beforehand
• Ask the organiser if you must attend and why
• Ask yourself How much value will I get from this meeting? and How much value can I contribute to this meeting?
• If the meeting organiser fails to end her session with specific next actions, take the initiative to ask what happens next

What other tips would you add?

Running great meetings was originally published in Trade Me Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Just last week, I started meeting each of the product managers to talk through their individual results, and to do some career planning. I’ve met with nine PMs so far, and one consistent pattern is a desire to do more public speaking. This is especially interesting as it wasn’t an explicit item I was asking them to rate! Still, communication is one of the most important skills a product manager can have, so it makes sense.

The good news is that I think it is pretty easy to build up public speaking muscle. A Trade Me product manager can start with internal talks like a monthly product management guild session, or a Friday night Tech Talk or a Brown Bag lunch, and then move onto external meet-ups like Product Tank, before applying to speak at conferences like UXNZ.

One tip though — when presenting, try and think about the story you are telling. To Sell is Human, a practical book as much about story telling as it is selling, has some useful advice:

• When telling a story, use this format: Once upon a time ______________________________. Every day, _______________. One day _____________ ____________. Because of that, ___________________. Because of that, _______________________. Until finally ___________________. Also, read all twenty-two of former Pixar story artist Emma Coats’s story rules: http://bit.ly/jlVWrG
• Use rhymes. Rhymes boost what linguists and cognitive scientists call “processing fluency,” the ease with which our minds slice, dice, and make sense of stimuli. Rhymes taste great and go down easily and we equate that smoothness with accuracy. In this way, rhyme can enhance reason.
• Use one word. In his 2012 re-election campaign, President Barack Obama built his entire strategy around one word: “Forward.”
• Practice. How do artists get better at their craft? They practice, of course. But they also pay attention…With a small notepad or on your smartphone, jot down the great pitches you hear as you’re moving through the world — a shrewd advertising tagline, a mom’s request to her kid, a colleague’s plea for a new assignment. This exercise serves two purposes. It will make you aware of all the pitches in your midst. And it will help you see which techniques move others and which merely drift into the wind.
• Ask questions if you are trying to persuade people of your point of view. Beginning with research in the 1980s, several scholars have found that questions can outperform statements in persuading others.

One bonus communication tip:

• Be mysterious in your email subject lines. Want someone to read your email? People were quite likely to “read emails that directly affected their work.” No surprise there. But they were also likely “to open messages when they had moderate levels of uncertainty about the contents, i.e. they were ‘curious’ what the messages were about.”…Your e-mail subject line should be either obviously useful (Found the best & cheapest photocopier) or mysteriously intriguing (A photocopy breakthrough!), but probably not both (The Canon IR2545 is a photocopy breakthrough).

Now get out there and get presenting!

Presenting is storytelling was originally published in Trade Me Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.