12/12/2019
D-Code
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.
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.
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
PaymentQ1: Internals
"Product black box"
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
PaymentQ1: Internals
Define your roles
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
PaymentQ1: Internals
Build your execution flow
Roadmap
- 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
PaymentQ1: Internals
Build your org-chart
PaymentOrganisation
PaymentQ1: Internals
Don't give up on the vision (& the business)
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
PaymentQ1: Internals
Driven team with Impact
PaymentQ2: Externals
Overcommunicate & Sync
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
PaymentOvercom'
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
PaymentSync'
PaymentQ2: Externals
Transparent Execution & Impact
Build Trust
Thanks!
Don't hesitate to reach out at hugo@side.co

Demystifying the product black box

  • 1.
  • 2.
    PaymentIntroduction Created in mid-2015 Marketplaceconnecting 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 everbeen 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
  • 5.
  • 6.
    PaymentIntroduction Q1: How doI 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
  • 7.
  • 8.
    Organisation - What isPM? 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
  • 9.
  • 10.
  • 11.
    - Ratio betweencommitment 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
  • 12.
  • 13.
  • 14.
    PaymentQ1: Internals Don't giveup on the vision (& the business)
  • 15.
    Vision No, reading areport 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
  • 16.
  • 17.
  • 18.
    PaymentOvercom' No, people don'tread 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
  • 19.
  • 20.
    PaymentSync' Know what's happeningin 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
  • 21.
  • 22.
  • 23.
    Thanks! Don't hesitate toreach out at hugo@side.co