This document discusses how to drive a product team internally and communicate externally as a CTO.
Internally, it recommends defining roles like PM, PO, and QA even if not filled; building an execution flow with roadmaps, velocity tracking, and scrum rituals; keeping the team informed of the business vision; and ensuring features have proper context.
Externally, it suggests overcommunicating through roadmaps, training, newsletters, and selling the product simply; and syncing by knowing other business units, doing user interviews, and having regular stakeholder alignment through 1:1 meetings and projects in tools like Asana.
The goal is transparent execution to build trust with stakeholders and ensure the product
2. PaymentIntroduction
Created in mid-2015
Marketplace connecting temp workers and companies
Available in 14 cities in France
-
100+ employees, 30+ in Product Team
Big bet on product, first team built
React/redux, Golang, Swift & Kotlin, AWS, Gitlab, Docker, etc.
3. PaymentIntroduction
×
Hugo Michalski
Currently CT(P)O @ Side. First, developer as the only technical
founder, now leading Product Team with tech, product
management, design and data.
Responsibility: translate vision and business opportunities into a
tangible product while maxing out Side's Product Team efficiency
& impact.
4. PaymentIntroduction
Have you ever been told:
- "Am I really more than an executant?"
- "Does tech really understand our business challenges?"
- "I feel like most of my time is spent reporting"
- "How can I be more informed, impactful and aligned with customer need?"
- "But what have they done, really, in the product?"
- "Why do they need so much time just to add a button?"
Explaining the Product
6. PaymentIntroduction
Q1: How do I drive my team?
→ What to put in place in my team to keep them on edge with the business
Q2: How do I communicate externally?
→ Excom, investors, users, insiders
Demystifying the black box
8. Organisation
- What is PM? PO? What about QA, UX, PMM?
- Do I need these roles today?
- Who is taking this responsibility for now?
- Does it scale?
- What happens between ideation and adoption?
- Is my current organisation still efficient when we'll be 5 times more?
- How can I scale nicely with more typologies of users, employees, usecases?
Even if you don't have a FT employee for some of these roles, it's never too early to map them in your organisation
11. - Ratio between commitment and what was delivered
- Normal set at 75% to go after stretch
- Breakdown for the whole team, each squad, each
individual
- Monitoring tool for the team to understand and act on
positive or negative deviations
→ Looker + Asana (API)
→ 1w sprints
→ Time estimations on tickets
→ Follow scrum rituals
PaymentVelocity
Velocity
15. Vision
No, reading a report every quarter won't save you
→ Go to client meetings, have your team go too
→ Handle your customer support (with shifts)
→ Talk to the people facing users
→ Never assume that your team and you are equally informed
→ Repeat over & over the context 7x (weekly team points)
→ All features deserve context
→ Workshops with the team (quarterly)
Be quali & quanti
A product doesn't sell by itself, and doesn't sell at all when disconnected from business
18. PaymentOvercom'
No, people don't read the documentation
→ Roadmap timeline
→ Train teams with materials to help them better perform
→ Repeat yourself (7x)
→ Sell your product
→ Keep it simple and visual, market your points
→ Product Newsletters (investors, internal, users)
Be pragmatic
You are ultimately responsible for what was invested in a feature, discovery is as important as rolling it out
20. PaymentSync'
Know what's happening in other BUs
→ How do you plan to grow, who does what and when. Be macro
→ User interviews, CRM data, BI reports
→ Quarterly strat-plan, alignment with excom, focus on a few key points rather than trying to do everything
→ Asana Project for 1:1s with all your stakeholders, be stubborn with, it must become a norm
Sync yourself
Sync is timely, predictable and simple. Tools should be as scarce as possible