How do you establish an effective product management team?

I returned to Bristol recently to guest host the Threads meetup. Clearly I didn’t put them off the first time. Threads is a monthly roundtable discussion for entrepreneurs and founders of technology scale-up businesses based in the South West of England.

This month we were discussing when and how to build a product team.

If you’re interested in learning about how to build or improve your own product team, handily I can provide you training on that very topic.

Contact me if you’d like to attend product management training or would like me to speak at your event.

You can read the write-up below.

(Reproduced from the Techspark blog, article by Andrew Gifford and me.)


Founders often remain too closely involved in the day-to-day running of their business to retain an impartial perspective of ever-changing product:market fit.

As a founder, you must not be precious about devolving responsibility for your product management to someone better skilled. With the increasing demands on your time to run and promote the broader business, ceding control of your products to a dedicated product manager will also help to protect you from burn-out.

Here are some tips from Founders of South West tech scale-up businesses, taken from the 2019 series of Threads meetups, helping you determine how best to identify the right person to look after your product.

A product voice at board level

Product management must have a voice that’s listened to at board level, during all stages of your company’s growth. If this seems strange, consider how important it is to your revenues that your product is a success!

Jock says: In larger organisations with multiple products, there should be a Chief Product Officer with a seat on the board, peered with the others in the C-suite. In smaller (or flatter) organisations, there still needs to be an equivalent senior product manager responsible for the product strategy (the ‘what’ and ‘why’), the product team (the ‘who’) and the product discipline (the ‘how’).

Suggested reading: Product Leadership by Richard Banfield, Martin Eriksson and Nate Walkingshaw

A driver to appoint a product manager – be they employed, contracted or outsourced – usually arrives organically, when the founders become too operationally focused to effectively evolve the product.

A product manager operates at the heart of your business. As a generalist, they may not have all the tools, or answers, but will have the right questions and people skills to understand and collaborate with those who do.

Jock says: A good product manager should have an good appreciation of diverse skills ranging from design to development to marketing, and everything else needed to make a product successful. The goal is not for the product manager to be an expert in all these disciplines, but to understand enough about each to have a sensible conversation with an expert in each field.

After all, it would be practically difficult to gain 10-15 years’ experience as a dedicated developer, then again as a designer, then as a user researcher and so on! A product manager is a generalist who draws on the expertise of their team of specialists.

Suggested reading: The Practitioner’s Guide To Product Management by Jock Busuttil

The principles of product management

Product management isn’t just a person or function. It is a set of principles.

Jock says: The principles that underlie product management don’t dictate a rigid process, but instead guide the individual towards the right approach. There is no definitive list, but mine would include:

  • Put users first
  • Be human and ethical
  • Understand the problem before trying to solve it
  • Put yourself in their shoes
  • Serve, don’t lead
  • Have just enough process / documentation / meetings to get by (but no more)
  • Show, don’t tell
  • Face-to-face communication for the win
  • No finger pointing
  • No ego
  • You are not representative of your users’ needs
  • Use data and evidence to inform and guide (but not dictate) decision-making

When to hire your first product manager

The tipping point to appoint a product manager often arrives after angel or series A funding, where founders have little headspace for fresh thinking. Too-busy founders risk becoming out of touch with user needs, arriving at an opaque understanding of current and emerging trends.

If you’ve never appointed or hired a product manager, get an experienced adviser to support the selection process; together you can identify the right skills and attributes for your product aims and weed out the obvious non-starter candidates.

Jock says: The same goes when hiring any discipline that’s new to your business. Whether you’re hiring your first product manager, designer, user researcher, devops engineer, or whatever, you need someone who knows what good looks like (and who can call out bullshit) to interview them on a technical basis, in addition to your ‘cultural-fit’ interviewing.

There isn’t yet a trade body that speaks for all product management professionals. A range of qualifications and certifications exist internationally, each offering certain merit and varying methodologies.

It’s best to appoint someone in who brings a collection of relevant skills, tools and methodologies that suit the values, aims, stage and markets of your business. Explore how well the principles are understood by each candidate and how they apply a pragmatic and flexible approach.

Jock says: Often people make the mistake of thinking that product management is a variation of project management. There are many certifications and training courses that dictate a particular rigid process or framework to follow to create a successful product. This creates a similar problem to a handyman whose only tool is a hammer – every solution to every problem becomes the same. Instead, a good product manager should have multiple approaches (tools) available to them, and can choose the most appropriate approach given the circumstances.

Think of the differences in approach needed between:

  • managing a new product in its early growth versus a declining product
  • operating a product in an emerging market sector (e.g. autonomous vehicles) versus an established one (e.g. insurance)
  • working in a startup with 15 people in one room versus a multinational group company structure

One of the tricky things about product management is that what is considered best practice has evolved rapidly over the last 20 years. It’s gone from being a process-heavy set of sequential steps, influenced heavily by traditional project management and marketing practices, to being a much more human-centric, fluid, adaptable and process-agnostic discipline. Certification syllabuses haven’t really kept up with the times, so even a relatively recent certification in product management may still mean out-of-date practices.

Hiring a good product manager

It’s best to ‘hire for characteristics’, as a good product manager will soon get to grips with the issues and opportunities in your domain.

Arguably, unless you are operating in a deeply technical or specialist domain, hiring for prior domain expertise can become an unnecessary blocker to appointing someone who brings a fresh perspective, missing out on cross-fertilisation of ideas and successes from other domains.

You’re looking to appoint someone who has a lack of ego, a curious and investigative mind, resourcefulness, and an evidence-led and data-driven approach. Creativity and experimentation are important, but must be backed by an analytical approach.

You’re looking for someone who listens well. Someone who coerces potentially reluctant people into a cohesive direction.

You will likely appoint a ‘T-shaped’ person – someone who brings a depth of expertise around one particular area, perhaps reflecting the individual’s background in technology / user experience / the commercial aspects – with a supplementary appreciation of all the other disciplines needed to create and deliver a successful product (marketing, sales, digital, delivery, project management etc.).

Technology usually proves to be the easy bit, because – while you can make technology do the wrong thing – you are dealing with knowns. The spanner in the works is usually the many people involved: their misconceptions and reluctance to change. A good product manager identifies the unknowns, evidences the user needs and options, and works with their team of specialists to identify, test and deliver solutions to user problems.

Don’t be afraid to hire someone who is quite different from you, and who is healthily different from the team. Diversity of thought and approach is an important asset for a distinguished product.

It’s reasonable to expect your new product manager to get up to speed on your company, market and domain within a month – even with little prior domain knowledge. They will need your backing, and exposure to all aspects of your business, its users and markets (but don’t let the Sales team accompany them during the initial research).

The emperor’s new clothes

Your new product manager should be asking beautifully simple questions, ‘why does the emperor have no clothes on?‘. Their newness and naivety is an asset that can challenge outdated working practices, received wisdom and other ingrained bad business habits.

It’s important that your product manager/people keep things fresh – not least themselves – also their approach, the people they work alongside and the methods used. Change the seating plans occasionally, operating in multidisciplinary teams. Switch them between different products every two or three years.

Suggested reading: Social Physics by Alex Pentland and Building Successful Communities Of Practice by Emily Webber.

Don’t silo your people away from each other. Get your people to spark off each other, sharing perspectives across different disciplines.

Your product manager should be away from their desk 75% of the time; conducting research with users, visiting prospective customers, getting to grips with the market, and collaborating across multidisciplinary teams and partners.

It can be useful to seat your product manager near the coffee point, for easy ideas swapping and information exchange. They will likely get to know when you take your tea break, for five minutes of your time to exchange ideas and knowledge.

A product manager who was previously dispassionate about your domain usually brings fewer prejudices. They won’t have to suppress their personal views while synthesising the fresh evidence before them. You can always pair them with domain experts later while you test the new thinking.

A product manager abstract the dynamics of the market, building and refining and mental map.

Jock says: There are a handful of established market models that broadly exhibit similar characteristics and dynamics, regardless of the market sector.

Marketplace products that connect buyers and sellers behave broadly the same regardless of whether the goods being bought or sold are second-hand cars or financial derivatives.

Products showcasing and monetising user-generated content will again follow similar patterns of behaviour whether the content is videos or long-form writing. And so on.

You may wish to believe that your product and market are unique, but everything is always a variation on an existing theme, even if modernised with new technology.

Suggested reading: Lean Analytics by Alistair Croll and Ben Yoskovitz

An appetite for continual learning

A product manager should have an appetite for continual learning.

Jock says: Everything is continually changing and evolving. User needs become more sophisticated as the bar is raised for them by other products; markets grow, mature and decline; new technologies become available; new approaches to product delivery fall in and out of favour.

A good product manager keeps abreast of the major advancements that will have a bearing on their product, market or team. This means they are continually learning and enjoy doing so. Product managers are excited by the potential of new things, but temper that excitement through objectivity and practical evaluation of suitability.

Hire experience first

You don’t want your first product manager to be learning the trade (as a product manager) while also getting to grips with being the first product manager in your organisation. It’s best to appoint an experienced person first – perhaps contracted or outsourced – to identify the strategy and establish the product management function. You can always pair them with an up-and-coming team member, to grow the function.

Jock says: This way, the product management practices themselves should not be in question, leaving the product manager to get on with the already tricky task of establishing a new product function in your company.

If considering internal candidates for a trial in product management role, look for someone who is already lobbying on behalf of the product or users and working well across different departments. This person will likely be multiskilled, displaying attributes of curiosity, experimentation and an evidence-based approach.

Setting up your team

Multidisciplinary teams, sharing diverse viewpoints and strengths are an excellent way to collaborate productively. You can effectively seat together up to 12 people in a cluster of desks. It gets a bit unwieldy beyond this.

Jock says: More about multidisciplinary teams here: I Manage Products – Assemble the Right Product Team by Jock Busuttil

Encourage the use of visual aids, whiteboards and collaborative working spaces, illustrating the ‘now, next and later later’ plans, (also known as your product roadmap) and UX feedback. Promote face-to-face conversation and ideas exchange. Your digital or project management system mustn’t dictate the way people work.

A collaborative culture

Publish your UX research and product plans visually at tea/coffee/water points. Work visibly and openly, so that others can chip in their own findings and perspectives.

Establish a culture of a weekly show and tell, at a regular fixed time in the calendar and lasting 45 mins maximum, with five minute talks followed by five minutes of Q&A each. Foster a culture where attendance is habit and everyone is welcome (not just techies). Someone from (if not all of) the leadership team must attend to set a good example and gain valuable insights. Ban Powerpoints – it makes preparation too onerous, and never fits into 5 minutes. Encourage ‘showing the thing’ instead.

Remote working

An entirely remote product manager can work effectively, provided the communication tools and culture of working with remote workers is already in place. It can be more of a challenge if your product manager is entirely remote in a culture where everyone else is physically together and not used to accommodating remote colleagues.

Jock says: A good case study in wholly remote teams is available at 18F. 18F is broadly equivalent to the UK’s Government Digital Services: 18F’s best practices for making distributed teams work

Your technical support team should work closely with the product team. These colleagues have excellent user and product insights, and a holistic view.

Further reading

Threads meetups are a way for founders and department heads of technology companies to share learning, experiences and conundrums. These roundtable discussions unpack topics around leadership, business and operations. Most people find at least one improvement to take away and implement.

Threads is held at 6:00 – 8.30pm on the first Wednesday of each month. To RSVP, head to the Threads South West meetup page.

For more Founder’s scaleup tips, follow Threads on twitter.

Threads II – The Sequel

If you’re in or around Bristol and are a tech founder or leader, I’ll be hosting the February Threads meetup again. Like you, I have no idea why they invited me back.

We’ll be talking about when and how to build a product team on Wednesday 6th February from 18:00 at Ashfords LLC, Tower Wharf, Cheese Lane, Bristol, BS2 0JJ.

Sign up to attend on Meetup.

Product management has evolved. Has your company?

I popped over to Bristol recently to guest host the Threads meetup. Threads is a monthly roundtable discussion for entrepreneurs and founders of technology scale-up businesses based in the South West of England.

This month’s topic was on product management in general. For most around the table, it was a completely or relatively new concept, so our lively discussion started with the fundamentals.

If you’re also interested in learning about the fundamentals of product management, handily I have a day’s training course that covers that very topic.

Contact me if you’d like to attend product management training.

You can read the write-up below.

(Reproduced from the Techspark blog, article by Andrew Gifford and me.)


Founders of a scale-up technology business run the risk of building a product that no-one needs, nor wants, if they overlook the importance of understanding and capturing user needs.

Accept that, in the beginning, you know the least. Identify what it is that you need to know, or don’t know, and then go and find out.

Nurturing a user-focused culture will enable you to create a successful MVP, and then scale it well, prioritising the features that your users want and will pay for.

Here are some tips from Founders of South West tech scale-up businesses, taken from the 2018 series of Threads meetups, helping you to make the best use of product management.

What is a product?

A product is anything that provides value. It may be tangible or intangible, and this may include services or people resource.

Before someone can justify switching to your product, they have to want to fire the incumbent. To counter this inertia, aim to make a product that’s 10 times better!

Jock says: Users always have a choice. They can choose to solve their problem a different way or not to bother solving the problem at all. Whatever problem your product solves, it has to be as frictionless as possible – including the effort for the user of changing their habits to use your product in the first place. And this absolutely has to be less effort for the user than simply putting up with the status quo.

Most products differ substantially from their original guise; it’s easy to forget this, due to survivors bias! Hindsight is one way to learn and evolve, but first, you’ve got to earn it!

Jock says: Hindsight is a reflection of being better informed. Similarly, business risk is a measure of uncertainty – the less you know for sure, the greater the risk. Reduce your uncertainty and risk through research, experimentation and learning.

There is very little that’s truly new. Accept that you are just making things better, MUCH better. It’s better to do one thing, or a small number of things, exceptionally well, than to spread your product too thinly.

Defining success

You will see benefit from taking a servant-leadership approach. Your Product Manager doesn’t call all the shots, their role is to clarify and evidence the goals and to get a group of experts to align and deliver, all on the same page.

In defining success, ask of yourself;

  1. Do I really understand why users buy my product? Separate the demand (volume) from the need (why). The best way to do this is to go and talk with your users to see the context within which they’re working. Understand their problems, drivers and the implications. Watch for other underlying factors or inefficiencies that you may want to solve in the future.
  2. What does success look like for your end user? What characterises success, first for MVP and then for full launch? If the initial launch wasn’t successful, what should be changed to address this as priority’?

Early product adopters are invaluable but typically have differing needs from the major market. They may help shape the product but shouldn’t define it entirely. Their own needs will also evolve, grow and mature.

Expose your product to users as early as possible and throughout its development life cycle.

Define what success looks like for the different user groups, including your own goals, and how well these are achieved. Ensure you’ve understood the goals correctly.

Features are merely a by-product of helping someone.

Jock says: Remember the example of the petrol gauge in the discussion. The user problem is that he or she doesn’t want to run out of petrol. You can solve their problem in many different ways, but without understanding the user’s context, and what will work for them and what won’t, it’s difficult to come up with the best solution for their needs. Once you truly understand the user and their problem, the solution will suggest itself, and the features you actually build will come out of that. That’s why you don’t start with features. You start with user goals.

Gathering user feedback

Gathering feedback is best done face-to-face, or via video or screen share. A nice indication that you’re getting something right, is users saying “oh my god I didn’t know I could do that, this will help me loads”! You must absolutely nail this, aka the ‘product:market fit’. Work towards these ‘OMG moments’ as defacto standard.

Fake doors and telemetry can be cost-effective for testing a new concept, measuring clicks and patterns. This shows what’s happening, but never why it’s happening. You need to verify both the qualitative and the quantitative perspectives – each presents questions to the other.

Jock says: Quant analytics may tell us that users are dropping out of our shopping cart process at a certain stage. But without going and speaking to them (qual analysis), we have no idea why.

Once we have a better idea of why, we can create an experiment to test possible ways to improve the drop-out rate. So we might reckon that making the ‘Buy’ button more prominent might help, then we run an A/B test (another quant bit of analysis). We find out that a more prominent button improves the conversion rate for desktop users, but not mobile ones. We need to find out why, so we do more qual analysis (talking to users). And so on.

When selecting users from which to seek product feedback, work with the users to whom your product matters the most. Take a balanced view incorporating feedback from your most vocal users too, noting that they are typically either delighted or disappointed.

Jock says: Also, if your resource is limited – say, if you’re a startup – consider prioritising the group of users that you’ll be able to get hold of to speak to most easily.

Work to find the evidence from your users as to the problems that they need to solve.

Balancing your product team’s time

It can be difficult balancing the need to deliver new features that are visible, with the internal housekeeping, maintenance and technical debt management. Accept that ‘a good time’ to resolve housekeeping issues never fully arrives, so chip away constantly.

Every product release is instantly legacy. Everything that you can clean up makes your engineering team quicker, so they can develop a better product and ship it faster.

Also look for ways of improving your own business too, or freeing extra capacity. You can apply business analysis tools and methods to reduce tomorrow’s legacy. Improvements may, or may not, be external facing. (Your support teams/developers / etc. are also users of your product – internal ones.) Speed of experimentation, learning and delivery should be part of the criteria for success.

Jock says: Regular organisation-wide retrospectives can be a way to identify improvements to how the business operates – and how pleasant a place it is to work at. Treat each action from the retrospective as a measurable experiment. “If we try this, then we should see these specific results by this point in time.”

Jock says: Technical debt always accrues, so the best approach (if you can’t avoid it, to begin with) is to tackle it little and often. Devote a day a week each week for squashing pre-existing bugs and dealing with technical debt. Sometimes technical debt is more chunky, such as needing to refactor a major bit of the product, in which case have a ‘firebreak’ – a week or four – devoted purely to reworking existing code rather than creating new stuff.

Working to three-year refresh cycles is a sensible time frame and pace within which to manage your products; you should effectively rebuild your product every few years given the pace of technological change.

The best person to manage user engagement is someone with both the temperament and the rigour to ask informed questions and solicit unbiased feedback, and then to analyse the data, synthesising this into pointers towards solutions. Encourage engineers and the rest of the team, to observe user needs frequently.

You are not asking your users if they ‘like’ the product, you’re asking them what problem it solves.

Foster an culture of openness

Promote a culture that is open about the business goals and also hurdles or short fallings. Be open and transparent or you will suffocate ideas about how to address these.

Do not punish mistakes. Failure of an experiment is just another learning point. You will rarely never get something perfect from the off.

Keep the conversation going with your staff about the problems users face, ideas which may help and potential solutions.

Post up your product backlog, roadmap, user research findings and designs on available wall space. Invite discussion, encourage staff feedback. Plaster the office walls with this – kitchen, coffee machine or water point – mirrored on Trello (or equivalent) systematically. Spark conversation among a diverse range of colleagues.

Measuring outcomes not outputs

To measure product’s success, understand what it is that you expect to change, and by how much. Define a hypothesis, construct the experiment and measure effectively, with an appropriate scale.

It is better to measure outcomes (qualitative; the real-life difference that the product makes) than outputs (quantitative, the volume by which the product is used, or how many things you make).

You must understand outcomes in real-world terms; new customer sign-on time is quicker, releases can happen more quickly, or website sales are converting. How well is the user able to achieve their desired goal successfully?

Avoid ‘vanity metrics’ that have little bearing, even if these seem to satisfy the board or investors; e.g. clicks, page views, referrals from Twitter.

Jock says: A good metric is one that prompts you to remedy it and you know which specific action will directly cause the numbers to go up or down. A vanity metric doesn’t have any obvious remedial action because you’re not in control of its causes.

e.g. Page views is a vanity metric because it may go up or down due to the time of day, whether search engine algorithms happen to favour your content that day, or whether people are searching for those particular keywords – none of which is in your direct control. Moreover, page views usually have no correlation with the success or failure of your product, so why bother counting them? Croll and Yoskowitz’s Lean Analytics is a recommended read for measuring the right things.

An example of a better metric might be to track e.g. the number of commonly-purchased products displaying as ‘out of stock’, as this will most likely have a direct correlation to potential customers dropping off your site and failing to convert. You can take remedial action by ensuring that you know which items are most commonly purchased, and to replenish stock more quickly before it runs out.

Jock says: Express sprint lists and project targets in real-world terms that are focused on human outcomes.

  • At the end of this sprint, users with impaired vision will be able to navigate our website at least twice as quickly
  • At the end of this sprint, our internal support teams will be able to see a customer’s complete support history when they call, which will reduce the time a customer needs to be placed on hold by 80% and should increase customer satisfaction ratings of support by at least 3%.
  • At the end of this sprint, Android users with a fingerprint sensor will be able to use it to unlock the app instead of entering a passcode so we should see a 50% reduction in app login times for that user segment.
  • At the end of this sprint, teams will be able to deploy new code to staging and production in under 5 minutes, including all required tests.

Having access to measured data can be handy evidence in answering Freedom of Information request – an FOI request is usually someone asking for specific factual information from a government body, so having access to relevant measured data is usually helpful, rather than having to research it from scratch.

Minimum viable products

What is a minimal viable product (MVP)? Simply, it’s an experiment from which to learn, delivered as a small collection of features that solve a set of problems for a group of people.

An MVP must solve at least one of the problems that it addresses completely, allowing for the scale and complexity of the problem.

You should be able to sell a MVP for money (reasonably). It is absolutely ok to charge users while learning from them at the same time.

A ‘Wizard of Oz’ approach is ok, whereby the mechanism is invisible behind the scenes, the user doesn’t care, so long as the need is met.

Jock says: Google ‘concierge MVPs’

If you go too broad and try to solve all the problems you risk spreading your product too thinly. Do one thing really well; the one thing that (a small group of) users really want!

Early adopters will want to experience your product claims in the real world, and for it to be measurable. Don’t bullshit your users.

As a newcomer, building a sense of trust can seem a Catch-22. Experiment to find the least acceptable risk for your product users, demonstrate your product’s capability, then ramp it up. Accentuate efforts on establishing trust; e.g. accreditations, referrals, standards, associations or partnerships with established brands.

Your competition will always be there and, even if you are enjoying low competition, your users will always eventually go another route. Isolate and solve their priority problems, and make the complicated look simple.

Don’t be afraid to fake it while you make it.

Find people – colleagues, users – who can challenge your status quo, and who can poke holes in your approach and product, and apply objectivity while you improve.

We anticipate holding a follow-on discussion with Jock in early 2019.

Further reading

Threads meetups are a way for founders and department heads of technology companies to share learning, experiences and conundrums. These roundtable discussions unpack topics around leadership, business and operations. Most people find at least one improvement to take away and implement.

Threads is held at 6:00 – 8.30pm on the first Wednesday of each month. To RSVP, head to the Threads South West meetup page.

For more Founder’s scaleup tips, follow Threads on twitter.

The secret behind meaningful product roadmaps

I gave a talk recently about how I’ve been using data and analytics to guide my decisions in product management. I’ve edited the transcript a little and split it into bite-size parts for your entertainment. This final bit tells the secret behind meaningful product roadmaps. The previous bit was about the benefits of open and transparent data.

Continue reading

The benefits of open and transparent data

I gave a talk recently about how I’ve been using data and analytics to guide my decisions in product management. I’ve edited the transcript a little and split it into bite-size parts for your entertainment. This bit is about the benefits of open and transparent data. The last bit was about how UK government digital services gather and use evidence.

Continue reading

How UK government digital services gather and use evidence

I gave a talk recently about how I’ve been using data and analytics to guide my decisions in product management. I’ve edited the transcript a little and split it into bite-size parts for your entertainment. This bit is about how UK government digital services gather and use evidence. The last bit was about why we can’t help jumping to conclusions.

Continue reading

Why we can’t help jumping to conclusions

I gave a talk recently about how I’ve been using data and analytics to guide my decisions in product management. I’ve edited the transcript a little and split it into bite-size parts for your entertainment.

This bit is about why we can’t help jumping to conclusions. The last bit was about expensive and risky assumptions (and why you should check them).

Continue reading

Expensive and risky assumptions (and why you should check them)

I gave a talk recently about how I’ve been using data and analytics to guide my decisions in product management. I’ve edited the transcript a little and split it into bite-size parts for your entertainment. This bit is about expensive and risky assumptions (and why you should check them).

Continue reading

Getting better at public speaking

I’m currently working to improve my public speaking, and I recently gave a talk on Digital Justice at Product Management Festival in Zurich. Afterwards, I asked a few people for some honest feedback, and jotted down how I felt I’d done. So this post is really a mini-retrospective with me reflecting on what went well and what I could do better next time.

I thought you might find it of passing interest also. With any luck, I’ll present better next time.

Very large screen + very small Jock

Very large screen + very small Jock

Continue reading