post

Footer About

Footer Contribute

Footer Get Involved

Footer Links

Mind the Product

Guest Post

Why setting short-term goals can be problematic for high-tech companies

Product Management

Sunday Rewind: Video: Hardware vs software product management

B2B product management

Artificial Intelligence (AI) & Machine Learning (ML)

Building Product Teams

Business Strategy

Data Driven Product Management

Digital Transformation

Diversity and Inclusion

Minimum Viable Product

OKRs

Prioritisation

Product Design

Product Research

Product Development Process

Product Ethics

Product Discovery

Product Leadership

Product Management Career

Product Strategy

Stakeholder Management

🌎 <a href="https://www.mindtheproduct.com/world-product-day/" style="color:#FFFFFF;text-decoration:underline;">Happy World Product Day!</a> Be sure to celebrate product, yourself, and your peers today! 🎉

Why is hiring product managers so hard?

What burnout taught me: Lessons from product managers

Meet the new AI CEO: Klarna’s bold customer feedback loop bet

What I learned from building products in Africa

What does it take to build world class products today? Ezinne & Oji Udezue (Co-Authors at ProductMind, ex-CPOs of Calendly, Typeform & WP Engine)

With his background in technical editing, community building and product marketing, Chris' approach to product management is inherently centered around user narratives. He spent the first few years of his career working with the B2B developer products, prototyped an experimental technical publishing platform along the way, and then kick-started the Mind the Product platform. You can find him at ProductTank, or on twitter as @camassey.

Product Manager

Chris Massey

In 2008, the Financial Times was redesigned in a supposedly Agile way &#8211; it took four years, they ended up just shipped what they had, and was not considered a resounding success. <a href="https://twitter.com/bedemccarthy">Bede McCarthy</a> talks about the latest attempt to update the FT.com site, and how they&#8217;re getting it right. The team has hit every major milestone on or ahead of time &#8211; internal and external alphas, getting traffic on the new platform&#8230; partly by making milestones less date-specific, but also (more importantly) by taking a different approach to product development.
They know how to build a website for media &#8211; want to get to a platform to experiment on ASAP. Separate product from platform. Not against &#8220;feature teams&#8221; but, in practice, web tech moves fast, but the work required to modify editorial flows (inc. APIs etc.) are slower. Platform team owns as much of the technology (down to CDNs) as possible! If you&#8217;re asking internal / external teams to make changes, the bottlenecks add up! Business agreed to lower standard of service (not 99% uptime or 24/7 support) to enable faster turnaround. Use pilot projects to test technology AND build support.
<h2>Early-Stage Team Manifesto</h2>
Self-Organising &#8211; No assumed support roles like business analysts, project masters or tester. If the team needs them, they&#8217;ll ask for it. Product manager not defining vision, but acting as a facilitator. As little process (whiteboards, story-points, meetings) as possible.
Empowered and cross-discipline &#8211; Strong sense of ownership leads to engagement and hard work. Push the stakeholders back, and let the team be jointly responsible.
Direct access to metrics &#8211; Team builds their own dashboard as they build product (as a priority). Access to metrics allows team to BE self-organising and empowered.
Co-located &#8211; This can be challenging, but it purely boils down to high-bandwidth communication, team alignment, and forcing the team to form good working norms.
Practice continuous delivery &#8211; in many tech-first companies this is how established dogma, but in a publishing business like the FT this is quite a challenge. Critical as it allows the team to build, ship and test features within days, rather than weeks or months.
Test with real users in every cycle &#8211; This is about learning as much as possible about your customers, but it&#8217;s also about building and maintaining momentum &#8211; if you know you&#8217;re demoing to real customers who are taking time out of their day, and who hold your brand in high esteem, then you&#8217;re likely to work harder to have something to show!
<h2>How to Prototype</h2>
There are a few key factors that contribute to the team&#8217;s ability to prototype well, and prototype fast. To start with, the team have a &#8220;shipping mentality&#8220;, meaning that they prototype before investing time on design, and they prototype and test in code (bringing in design skills if there is some traction). Once the team have a prototype, they focus on real releases and real traffic &#8211; it doesn&#8217;t necessarily matter what the source of that traffic is &#8211; it could be internal, it could be a random sample of your external traffic, or it could be a specific group of beta testers. It allows you to test features, and also prevents teams from building &#8220;dirty&#8221; prototypes which then need to be rebuilt entirely for production.
<h2>Testing, Analytics &amp; Metrics</h2>
To make sure the team have got a good handle on how the product is performing, and understand what to measure, it&#8217;s essential that they get constant contact with customers (in the case of the FT, subscribers &amp; registered users). It&#8217;s also helpful if you can capture information at the point when someone stops using your product, which the FT team have done by getting notifications whenever someone decides to leave the beta and go back to the mainstream site.
It is crucial to identify and agree key metrics ahead of time with the stakeholders. This means that you&#8217;ll be collecting good, valuable data right from the start. More importantly, it&#8217;ll move any conversations with stakeholders away from &#8220;which features to build and ship&#8221; (which the stakeholders shouldn&#8217;t be involved in), and towards &#8220;How are we performing against our metrics?&#8220;. Stakeholders have to agree to this, and then let the product team be empowered and autonomous.
<h2>Challenges &amp; Lessons</h2>
As powerful as this approach is, it isn&#8217;t right for everybody &#8211; some people find the constant questioning and effort to do cross-functional work to be incredibly draining. It&#8217;s also hard to scaling this kind of methodology. Although it&#8217;s not about good process, this way of building product does rely on there being a lot of clarity &#8211; not only around product vision and prioritisation, but also around who needs to be involved (and, by extension, who should not be involved) in any given piece of work.
Focus on building clarity within your team, and in your communications and visibility to the world outside your team. Work with your stakeholders to agree on ways to intelligently empower your product teams to have a rich understanding of their users, and to make decisions about how to improve the product, and to do so at speed.

core/freeform

Video

How one Hackathon sparked a whole new product at Transifex: Maya Toutountzi (Head of Product) — Product Unplugged

Breaking down misconceptions to create healthier teams by Adrian Howard

Modern-day leadership by Janice Fraser

5 key practices to build a better product, Adam Mullett, ProductTank Perth

Experiment like a boss by Merissa Silk

From opinion-based to evidence-guided product development by Itamar Gilad

A quick look at decision supervision by Lucy Spence

The F words of highly successful product organisations by Saielle DaSilva

Identify and manage imposter syndrome by Phyllis Njoroge

The good, bad, and ugly of OKRs by Jenny Herald

Building the Next Financial Times, Faster

Product Management Foundations BST

Product Management Foundations ET

ProductTank Amsterdam

ProductTank Edinburgh

ProductTank Casablanca

ProductTank Des Moines

ProductTank Auckland

ProductTank Birmingham

ProductTank London

ProductTank Philadelphia

ProductTank Washington

ProductTank Reston

ProductTank Sydney

ProductTank Dubai

ProductTank Prague

ProductTank Reading

ProductTank Jacksonville

ProductTank Raleigh

ProductTank Rio de Janeiro

ProductTank Buenos Aires

ProductTank Atlanta

ProductTank Orlando

ProductTank Santiago

ProductTank Los Angeles

ProductTank Palo Alto

ProductTank Pune

ProductTank Bielefeld

ProductTank Köln

Communication & Alignment BST

Communication & Alignment ET

ProductTank Vilnius

ProductTank Paris

ProductTank Dallas

ProductTank Frankfurt

ProductTank Milton Keynes

ProductTank Tokyo

ProductTank Norwich

ProductTank Pittsburgh

ProductTank Hamburg

ProductTank Denver

ProductTank Leeds

ProductTank Manchester

ProductTank Bristol

ProductTank Oxford

ProductTank Exeter

ProductTank Würzburg

ProductTank Columbus

ProductTank Malmö

ProductTank Chicago