My product management toolkit (22): how to create a product culture?

What can you do when you’ve joined a company that hasn’t (yet) got a proper product culture? Making it harder for you to do your job or get people’s buy-in. Unfortunately, this tends be harsh reality for a lot of product managers, who then become increasingly frustrated with a lack of progress or an unchanged mindset.

However, there’s no need to despair, as there are a number of techniques and tools to start instilling a product mindset and creating a product culture. In this piece, we’ll first define what product culture means and then explore ways in which you as a product manager can contribute to the creation of a product culture.

What is product culture?

Fig. 1 – Martin Eriksson, “What Is A Product Manager?” – Taken from:

If you look at the famous product management venn diagram by my friend Martin Eriksson it quickly becomes apparent how the three components of Martin’s diagram feed into my components of a strong product culture:

  • Customer understanding – We all know how easy it can be to pay lip service to ‘customer empathy’ or ‘understanding user needs’! However, a strong product culture begins and ends with your customers. In organisations with a strong product culture, all staff members interact with customers or are at least fully aware of their customer needs. Companies like Zappos and Amazon are well known for their focus on customer centricity factors (see Fig. 2 below). In my experience, signs of  non customer centric companies are those where only a small part of the business ‘owns’ the customer relationship or where the customer has become this imaginary persona for most staff members. Also, I encourage you to pose a healthy challenge to those people in the organisation who claim to “know what the customer wants” based on their experience.
  • Everything is geared towards creating great products – Throughout the company with a strong product culture one can find a strong sense of innovation, a desire to experiment in order to create great products. Etsy is a good example of a company that develops new products and services iteratively, constantly testing and improving on previous product releases. One of the telltale signs of a strong product culture is when employees possess what Marty Cagan refers to as a product mindset (see Fig. 3 below).
  • Value proposition and business model – A shared understanding of your business’ value proposition and business model is a clear sign of a good product culture. Alignment around the value you’re aiming to provide to your customers – combined with an awareness of who those customers are – is a critical part of a strong product culture, as it underpins the products and services that you put out there.
  • Curiosity and experimentation – You know that things could get challenging if you, as a product manager, turn out to be one of the few people in an organisation to ask ‘why’ and be curious. These are traits that can be learned and adopted, and the more innovative and customer centric businesses are those that aren’t afraid to be curious, learn and ‘fail well’. I heard a colleague of mine phrasing it quite well the other day when he spoke about “taking calculated risks”. In other words, taking risks in such way that you learn a lot – quickly and cheaply – about your riskiest assumptions, whilst any negative ramifications are limited or non-existent.


Fig. 2 – Steven MacDonald, How to Create a Customer Centric Strategy for your Business – Taken from:


Fig. 3 – Marty Cagan, Product Mindset vs IT Mindset – Taken from:

  1. Purpose.  In an IT mindset organisation, the staff exists to service the perceived technology needs of “the business.”  In a technology-enabled product organisation, the staff exists to service the needs of your customers, within the constraints of the business.
  2. Passion.  In an IT mindset organisation, product and technology are mercenaries.  There is little to no product passion.  They are there to build whatever.  In a product organisation, product and tech are missionaries.  They have joined the organisation because they care about the mission and helping customers solve real problems.
  3. Requirements.  In an IT mindset organisation, requirements are “gathered” from stakeholders, prioritised in the form of roadmaps, and implemented.  In a product organisation, we must discover the necessary problem to solve or product to be built.
  4. Staffing.  The IT mindset shows up very visibly in the staff and the roles.  The lack of true product managers (especially strong product managers), the lack of true interaction designers, the prevalence of old-style project management, engineers unfamiliar with the demands of scale and performance, the existence of old-style business analysts, and heavy use of outsourcing, are all clear examples of this.  I would argue the most telling manifestation of the IT mindset problem is that the product managers in IT mindset companies are typically very weak, and at true product companies they are necessarily very strong.
  5. Funding.  In IT mindset companies you find them still funding projects (output) rather than product teams measured by business results (outcome).   There are many serious problems with this antiquated model, and it generates all kinds of bad behaviour in the organisation as they try to work around the constraints of this system, but most importantly, it results in very poor ROI for the company because of the very high cost of finding out which ideas work and which don’t.
  6. Process.  In IT mindset companies, you usually find very slow, heavy, Waterfall processes, even when the engineers consider themselves Agile.  The only part that would be considered Agile would be at the tail end of build, test and release.  Much of this stems from the Funding issue above, but deciding what areas to invest in, staffing a team, defining and designing the solution, and release planning are all typically very Waterfall.  Technology-enabled product organisations simply must move much faster, and work differently, in order to deliver the necessary solutions for our customers and our business.
  7. Silos.  In IT mindset companies, people align by function, creating silos between the different areas of the business, product, user experience design, engineering, QA and site operations.  In contrast, in a product organisation, we depend on true collaboration between product, user experience design, technology and the business units.  In a product organisation we optimise for product teams, not for the individual functions.
  8. Organisation.  In IT mindset companies, engineering is often under a CIO, and “product” (if it exists at all) is often under marketing or absorbed directly in the business units themselves.  In product organisations, there’s a big difference between the engineers that support “true IT” and those that work on the commercial products,  The True IT engineers usually report to the CIO, and the commercial product engineers report to a CTO.  Similarly, product is not a sub-function of marketing.  It is a top-level activity on par with marketing and technology.  It is not so much the org chart that matters here, as much as a recognition that the way we manage True IT work is very different than how we manage commercial product efforts.
  9. Accountability.  In IT mindset companies, accountability frankly is a farce.  The people actually working on a project typically have no real say in what they are building, and sometimes even in how it’s built, and even when it’s due.  In theory, the leadership team could try to hold the requesting stakeholders accountable for the results, but if they do they immediately hear complaints that they didn’t get what they actually wanted, and because of delays and costs, critical things had to get cut, and so it’s certainly not their fault.  So management writes it off as yet another failed technology initiative.  In contrast, in a product organisation, we are measured by results.
  10. Leadership.  As with so many things, much of this boils down to leadership.  In IT mindset companies, the technology is viewed as a necessary evil.  It is a source of fear more than a source of inspiration.  Leadership in IT mindset companies is always looking for a silver bullet when it comes to technology.  Maybe they should outsource the whole mess?  Or maybe they can acquire someone else that hopefully has a better track record than they do.   In contrast, in a product company, technology enables and powers the business.  It is embraced and valued.  The people that create the technology are respected as the key contributors they are.  Leadership in a commercial product company understands that it’s their job to create the culture and environment necessary to nurture continuous innovation.

Where to start?

As daunting it may sound, starting to create a product culture doesn’t have to be overly complicated or onerous. As always, my advice is to smart small. Kick things off with some simple but targeted initiatives:

  • A visioning workshop to create a shared product vision – A product culture starts with a shared vision of what the product is (not), and what we’re trying to achieve with it for our customers and our business. Lack of a shared vision usually manifests itself in a product that wants to be too many things to too many people. As a product manager you can drive both the creation and the shared understanding of a product vision, starting with the facilitation of a visioning workshop.
  • Agree on a mission statement (and make sure it’s omnipresent) – Whereas a product vision is typically more aspirational and future oriented, a mission statement is all about the problems your business is aiming to solve right now (see Fig. 4-5 below).
  • Live and breathe clear values that underpin your (product) culture – Naturally, every organisation will have its own unique values – both explicit and implicit. However, there are a number of values that I believe underpin most product cultures: curious (see above under “what is product culture?”), courageous, innovative, open, trying and learning. Formulating and agreeing on such values is the easy part; truly embodying them on a daily basis tends to be much harder. For example, within my current product team, we’ve got a ‘team manifesto’ which encapsulates our core values and principles, and we use this as a living reference point, asking ourselves regularly whether we’re actually living up to our principles.
  • 5 simple ways to become more customer centric – Especially if you find yourself in a business with an IT mindset (see Fig. 3), bringing the customer into the picture can be difficult. However, I’ve discovered and applied five simple techniques that have helped me in making organisations and colleagues to think more about the customer and their needs (see Fig. 6).
  • Hire and fire for the right behaviours and values – A successful product culture depends heavily on the people within the organisation. This means that when you’re hiring product people, you’ll be looking for some of the key values that underpin your product culture. For instance, when I recruit new product people, I always try to filter out any ‘product janitors’ as quickly as I can, simply because it doesn’t fit with the values that I’m trying to instil into my product teams. Equally, this also implies that you sometimes need to make tough decisions and fire those employees who might be great people but don’t form a good fit with your product culture and its underlying values (see above).
  • Clear goals, celebrate success and failure – Outcomes over outputs. I understand people’s obsession with certain features or ideas, but I believe that businesses benefit from a continuous focus on goals and problems instead of of fretting over features. I’ve found a goal-oriented roadmap to be a great tool in terms of driving an understanding of common goals.
  • Continuous learning – In my experience, the ‘learning’ aspect comes from continuously exploring different ways to tackle a problem, celebrating success as well as reflecting on the ‘failures’. The more you can share these learnings with the wider organisation, the better. This helps in creating a culture where there’s full transparency with regard to both achieved results as well as those things that didn’t go according to plan. In turn, this breeds a culture of experimentation, taking calculated risks, experimenting and being open about the outcomes, whatever they are.


Fig. 4 – Elements of a mission statement:

For (target customer)

Who (statement of the need or opportunity)

The (product name) is (product category)

That (key benefit, compelling reason to buy)

Unlike (primary competitive alternative)

Our product (statement of primary differentiation)


Fig. 5 – Mission statement examples from Patagonia and Cradles to Crayons – Taken from:


Fig. 6 – How do we become more customer centric – Five simple ways to get there:

  1. 5 customers every fortnight – User research and usability testing don’t have to part of massive projects, getting input from thousands of customers. In contrast, engaging with 5 (target) customers every two weeks goes a long way in my experience. It gives you an opportunity to learn continuously, in tandem with your development work and product / feature releases.
  2. Team based user research – I learned from UX expert Erika Hall about the importance of collaborative or team based research. The key point here is that user research isn’t a one person job. People across the business will benefit from learning from and about their customers.
  3. Exposure hours – Similar to team based user research, the idea behind so-called exposure hours is to share customer learnings directly with team members and stakeholders, by them sitting in on a user interview for example and being directly exposed to customers.
  4. Feeling what users feel – In my previous company, Notonthehighstreet, we had a programme called “In Your Shoes” which meant that all employees had to spend one day at a customer and be part of their businesses and lives for a day. It was a great to experience first hand the problems and needs customers have, and understand their contexts better.
  5. Product retrospectives – Finally, I’ve found product retrospectives to be a great way of instilling a more customer focused mindset. Regular product retrospectives are a great opportunity for a team and the wider business to reflect on its products or services. How are our products performing? What did we release last month and how is that release doing? What are our customers saying, thinking and feeling? Product retrospectives are explicitly not about the team or process improvements. Instead it’s all about the product and its users.

Main learning point: Creating a product culture is by no means easy but as a product manager there are number of tools and techniques one can use to instil a product mindset and a more customer-centric approach.

Related links for further learning:


Jeff Gothelf and Lean UX

In case you don’t know, I’m a big advocate of “Lean UX” and the work of Jeff Gothelf on this topic. It was Jeff who originally coined the term ‘Lean UX’ and wrote a great book about it, together with Josh Seiden. In short, Lean UX is all about not doing all your product design upfront, designing in more iterative fashion instead. I recently attended a talk by Jeff in London, where he talked about the concepts behind Lean UX, and here’s what I learnt:

  1. Cut out the design phase – Jeff stressed that the traditional design phase, where design is done in isolation, needs to go. I totally agree. Far too often designs are being thrown over an imaginary fence and implemented in a way that didn’t match the desired user experience, as intended by the designer. Instead, designers and developers should collaborate around ‘transient artefacts’, a simple sketch or prototype (see Fig. 1 below), in order to come to a shared understanding. These artefacts are by no the finished article, but create a shared understanding of what we’re looking to achieve and why.
  2. So what!? – The main idea about being ‘lean’ and ‘Lean UX’ is to “do less, more often.” Instead of just focusing on shipping features as often as you can, Jeff argued that the goal should be to achieve specific user outcomes as frequently as possible. I can imagine that this means a change in mindset and approach for some product teams. I believe, however, the ability to constantly ask the question “so what!?” from a user’s perspective is critical to building successful products. Whether you ship 2 or 50 features per iteration, this becomes totally irrelevant if you’re not changing customer behaviour.
  3. Humility and risk mitigation – I personally believe that as a product persona, you need to have a healthy degree of humility, and Jeff addressed ‘humility’ within the context of assumptions. He acknowledged how hard it can be for all of us to admit that we don’t know what the end state of a product or solution is going to look like, especially when you haven’t spent months creating a full product specification upfront. However, this is a risk that can be mitigated by being humble, acknowledging that you’re making assumptions and picking the riskiest assumptions to test first. In practice this will mean that you’ll be doing user research and getting feedback as part of each iteration.
  4. Change definition of “DONE” – Instead of just taking a feature release as the final stage of the definition of “DONE”, Jeff suggested that “changing customer behaviour” should be the ultimate definition of DONE. You pick a tactical metric that reflects the impact that the product is looking to make on customer behaviour. For example, you focus on a leading indicator to represent ‘customer intent’ or ‘conversion’ and something is only considered DONE if you’re moving the needle on your chosen metric (see Fig. 3 below).

Main learning point: I always learn something new from Jeff Gothelf and it felt no different with his recent talk in London. The main thing I took away from his talk was the importance of focusing on user outcomes instead and changes in user behaviour, as opposed to just shipping features.

Fig. 1 – Visual depiction of a transient artefact – Taken from: 



Fig. 2 – Acknowledge that we’re making a lot of assumptions when building products –



Fig. 3 – Build-Measure-Lean and Think-Make-Check – Taken from:

Think Make Check


IMG_2814 (1)


Related links for further learning:


Why we need a PRODUCT retrospective

Any self respecting developer or product person will be doing team retrospectives on a regular basis. These retrospectives provide a great opportunity to reflect on past releases, build team dynamics and identify any areas which could be improved.

However, I’ve found product retrospectives to be a lot less common. Let me first explain what I mean by “product retrospectives”: a regular opportunity for a team to reflect on the product or service. This is explicitly not about the team or process improvements, it’s all about the product:

  • How is our product performing (or not)? – I appreciate that many of us will monitor product performance on a daily or even hourly basis. However, there might people in your business who don’t keep track of recent product releases or performance. They might also not be au fait with the assumptions – business and user – which underpin a particular product feature or improvement.
  • How are we doing against our roadmap and business objectives? – This is an opportunity to look at the bigger picture and review progress against key roadmap milestones and success factors. What have we been doing (and why)? What’s coming up and what’s the impact that we’re expecting?
  • What are our users saying? – If you’re getting user feedback on a regular basis, I find product retrospectives a great time to share user learnings and insights. This can be as simple as sharing excerpts or quotes from user feedback sessions or a video of users testing your product remotely .
  • What’s happening in the market? – To avoid looking at a product or proposition in isolation, I always try to look at competitors as part of a product retrospective. What are our competitors doing? Why? Similarly, I also like broadening perspectives by learning from businesses in different sectors or markets.
  • What product ideas do you have? – Facilitating a product retrospective isn’t a one way street. It’s also an opportunity for the people in the session to provide their suggestions based on the data and learnings that you discuss with them.

As with regular retrospectives, this is how I typically structure my product retrospectives:

  • Set the stage – I’ll outline the goal for the retrospective, identifying both the desired outcomes of the session as well as what I expect to cover. For example, I will explain how we will use the product retrospective to further shape the product roadmap and that some concrete product objectives are a desired retrospective outcome.
  • Gather data – To create a shared picture of what’s happened or is happening, I’ll start of by presenting hard facts around releases, roadmap progress, business objectives and key results. I’ll use these facts as a starting point for discussion, facilitating a conversation around data, underlying assumptions and problems to address.
  • Generate insights – This part of the product retrospective is about asking “why” and thinking about what could be done differently. At this stage, I’ll talk about qualitative user feedback and we’ll discuss the “why” behind some of our insights.
  • Decide what to do – At this point in the product retrospective, the audience is likely to have some product ideas or suggestions worthy of further exploration. From experience I’ve learned that the format of a product retrospective doesn’t lend itself particularly well to a lengthy discussion about the merits of a product idea. However, it’s a great opportunity to gather thoughts and to prioritise ideas for further discovery.
  • Close the retrospective – This is where I tend to do a quick recap of the main insights and actions discussed during the retrospective. I’ll also ask if there are any specific items that the audience would like to see covered in the next product retrospective.

Main learning point: Hopefully you can see how easy it is to to do a product retrospective and the benefits you’d get from doing this on a regular basis. I’ve done product retrospectives with single teams (e.g. development teams or marketing teams) but have also run them for ‘multi-disciplinary audiences’ (i.e. members from different teams in one room). In both cases, you’ll be able to create a shared understanding of product performance and get valuable feedback to help move your product forward.


Book review: “Collaboration Explained”

The book “Collaboration Explained” by Jean Tabaka was published in 2006 and had been on my ‘books to read’ list for quite a while before I finally got my hands on it. Jean Tabaka specialises in Agile software development and has worked closely with a host of businesses and teams to implement Agile methodologies. In “Collaboration Explained” she describes how to best run projects in an iterative and collaborative fashion.

The key focus of the book is on working with self-organised teams, empowering teams to make their own decisions. Tabaka’s core point is that this ’empowerment approach’ requires a different leadership style; a ‘servant’ leader whose role is to facilitate instead of the ‘command-and-control’ leader who leads the troupes and tells them what to do.

The book explains in great detail some of the ways in which one can help create self-organised teams and foster a culture of collaboration:

  1. What makes a collaborative leader?  In “Collaboration Explained”, Tabaka explains the core aspects of facilitative leadership: “as a profession, facilitators work as guardians for teams. They manage a collaborative process that guides decision-making, consensus building, and productive team outputs (…). A facilitator owns the process, not the decisions for which the process paves the way.”
  2. Collaborative teams that are self-organising – Naturally, in order to create a collaborative culture one needs a team that feels confident and empowered to work in a collaborative and self-organised way. The book contains references to Agile authors such as Pete McBreen and Jim Highsmith who introduced a shift in thinking about the role of project managers; instead of prescribing tasks for the team to execute, their role should be much more focused on defining a ‘mission’ and on building relationships within the team.
  3. Defining project collaboration events – A lot of the chapters in “Collaboration Explained” are dedicated to the artefacts of collaborative project and product management. Good examples are planning meetings and Scrum sprint planning meetings (see Fig. 1 and Fig. 2 below). At times I felt that a large part of the book was spent on how to best prepare and manage meetings, but I can imagine that many readers will find these practical pointers helpful.

Main learning point: “Collaboration Explained” wasn’t exactly the book that I hoped it would be. I hoped for more practical advice on empowering teams, giving the team the confidence to make decisions and on how to best create one project or product team. Too often I see occasions where managers are prescribing tasks for others to execute on whereas I really believe in shared responsibility, feeling accountable for the same mission in equal measure. I was therefore hoping for more suggestions on how to nurture such a mindset on an ongoing basis.

However, “Collaboration Explained” is great for readers who are fairly new to Agile development or who wish to learn more about effective meetings. On those aspects, the book provides a great deal of detail on concrete Agile artefacts and on how to get the most out of team meetings.

Fig. 1 – Planning Meeting Cautions (from “Collaboration Explained” by Jean Tabaka, p. 55)

  • Avoid extended status sharing
  • Make sure information sharing is specific to the purpose of the planning
  • Plan, don’t build
  • Don’t finish a plan without defining actions to support it

Fig. 2 – An example overview of a Scrum Sprint Planning Meeting (from “Collaboration Explained” by Jean Tabaka, p. 57)

  • Who is the product owner for this Sprint’s Product Backlog?
  • Who is in the project team for this Sprint?
  • What other stakeholders maintain “skin in the game” of this Sprint?
  • What is the full set of items in the Product Backlog to be considered for this Sprint?
  • What is the length of this Sprint?
  • What concerns does the team have about the Product Backlog and the length of the Sprint?
  • Based on these concerns, what changes must be made to the Product Backlog?
  • What is the final priority of the items in the Product Backlog?
  • What priority items from the Product Backlog are being placed in the Sprint Backlog?
  • Given the items placed in the Sprint Backlog, what are all the risks to be managed during the Sprint?
  • How shall the project team report its progress and risk management during the Sprint to the Stakeholders?

Related links for further learning:



Discovering more about social collaboration software

Recently I found myself looking into the world of ‘enterprise collaboration’ tools. The key thing I love about such applications is the amount of transparency they offer. Suddenly, discussions, thoughts, suggestions and documents become a lot more visible and accessible.

In a previous role I had worked a lot with tools like Jive and Basecamp and I’ve recently been ‘collaborating’ a lot through Asana and Yammer. It made me realise that even though a lot of these tools set out to provide a similar value or proposition, there are nevertheless some differences worth looking into:

  1. Online collaboration vs online project management (1) – People can collaborate around ideas or specific projects, or both. Yammer is great as a tool to collaborate around ideas whereas Basecamp and Asana are more geared towards project management. As my ex-colleague Daniel Siddle – who specialises in this area – put it: “real-time collaboration is a hard one to get right since the concrete end goal can be much harder to define and less tangible compared to using online project management software.” With project management software the tangible outcome is that you can deliver a project faster but with social collaboration software things can be a lot less tangible.
  2. Online collaboration vs online project management (2) – What I like most about using tools such as Yammer, Jive, Chatter (Salesforce) and Confluence is that they enable full transparency, keeping all relevant communications in a single place. When working on specific projects, tools such as Podio (see Fig. 2 below) and Basecamp (see Fig. 3 below) can provide visibility on project progress and on who’s doing what. One thing I learned from having another play with some of these tools is that most online collaboration tools also seem to have at least some project management functionality. Good examples in this respect are Yammer, Tibbr and IBM Connections. Employees can have lengthy discussions on these platforms but are able to switch into a more project management related part of the system if required. In contrast, some of the online project management tools that I’ve looked at seem less geared towards open collaboration.
  3. Some tools in the online collaboration space and what to look out for – Tools that come to mind are: Chatter, SocialtextIgloo, Jive, Yammer, Confluence, MangoApps and daPulse (see Fig. 1 below). As with any digital application, key things to look out for are (1) ease of use and clean interface design and (2) management of information. With some of the tools that I mentioned above there’s a risk of information overload, with the application becoming one long activity stream. Also, I’ve learned from implementing some of these tools with clients that the more intuitive it is to share and comment on ideas, the higher the uptake of these tools. I like tools such as Yammer and Jive because they are so intuitive and easy to use.
  4. Some tools in the online project management space and what to look out for – When managing projects of any scale and with a number of different people involved, Gantt charts or emails are no longer sufficient in my view. Tools like Asana, Basecamp, Podio, Trello and SocialCast provide private workspaces dedicated to specific projects and make it easier to keep track of project progress and outstanding tasks. Whereas a tool like Yammer is continually strengthening the project management aspect of its application (see Fig. 4 below), I find that Asana, Podio and Basecamp (see Fig. 2/3 below) can really help in assigning tasks as well as understanding the status of a project and its individual milestones. Another aspect to look out for is the secure sharing of documents. Most of the applications I mentioned above do have that capability, but there also platforms out there such as Dropbox and Box that do just that: securing storing and sharing of documents.

Main learning point: having used social and project management tools for a while now, it’s interesting to see an overlap in functionality and in proposition arising between the different tools. Like with most products the main challenge to the user is to be clear what they want get out of a specific tool and to establish whether it can deliver on that expectation. For instance, if one’s end goal is to deliver projects faster, some of the open collaboration solutions might not be appropriate. In contrast, if one likes to collaborate around ideas then the more traditional project management software might not be the way to go.

Fig. 1 – An introduction to daPulse by daPulse

Fig. 2 – How Podio can be used for Project Management by Podio

Fig. 3 – A review of the Basecamp project management functionality by Joel Milne

Fig. 4 – An overview of new Yammer features by Yammer

Related links for further learning: