Product management - Inseec Bordeaux 2015

Product Management

Bordeaux Janvier 2015

Philippe ALBERT

Diplomé MMI Bordeaux en 2008

Product manager MK2 de 2011 à 2013

Head of digital MK2 2013 à 2014

2

Objectifs de la journée

1) Aborder les mutations actuelles liées au numérique dans les entreprises

2) Sensibiliser aux nouvelles organisations et aux nouvelles façon de penser / concevoir des produits digitaux

3) Transmettre les clés pour s’adapter rapidement et s’intégrer aux équipes de production digitale

3

1) Réflexion autour de la transformation numérique

2) États des lieux de la conception des projets / produits en entreprise

3) Exemple d’une méthode agile : SCRUM

4) Assurer la gestion d’un projet (du commencement au Minimum Viable Product)

5) Sources & veille

6) Présentation retour expérience de mon expérience MK2 (site web / site mobile / app iOS)

7) Atelier définition d’un projet

Structure de l'intervention

4

Réflexion autour de la transformation numérique

5

Réflexion autour de la transformation numérique

6

Réflexion autour de la transformation numérique

Avant tout un changement de vision et de méthodes de la part des directions, responsables, salariés….

7

Réflexion autour de la transformation numérique

Remettre les consommateurs au centre de l’entreprise

● être plus réactif face aux demandes

● être en adéquation avec les besoins réels de l’

utilisateur et du consommateur

● plus de transparence (ouverture de l’accès aux

données)

8

Réflexion autour de la transformation numériqueÊtre dans une logique de collaboration :

● Partage de l’information

● Mutualisation des projets

● Mise en commun des procédures

9

Réflexion autour de la transformation numériqueDiffuser une culture data-driven

● Mise en place de tableaux de bord de performance

● Toujours justifier une décision sur des résultats

chiffrés avec un modèle défini en amont

● Diffuser les modèles de données

● Exploiter les données

○ datavisualisation

○ personnalisation des interfaces / contenus

10

Réflexion autour de la transformation numériqueDiffuser la culture lean

● Définir une hypothèse

○ tester

○ mesurer

○ apprendre

○ améliorer

Voir exemple avec des outils tel que :● LaunchingRock● LaunchGator

11

Réflexion autour de la transformation numériqueChanger sa façon de manager

● Responsabiliser les salariés (gestion de leur

temps / présentation des résultats de leurs

actions)

● Alterner les phases intenses avec les phases de

repos

● Savoir dire non et savoir argumenter pourquoi

● Ne pas rester au bureau jusqu’à 22H

● Arrêter de dire que vous êtes overbooké

12

Méthodes traditionnelles

Préparation demandées ● Spécifications fonctionnelles● Livrables attendus● Délai ● Budget

Avantages● Tout est documenté à l’avance● Contrat négocié à l’avance (peut être à l’avantage financièrement pour le client dans le cas d’un

projet au forfait)Inconvénients

● Problèmes d’adéquation entre les livrables finaux et le besoin réel de l’utilisateur● Effet tunnel (trop de fonctionnalités en trop de peu de temps)● Augmentation du risque de la dette technique● Trop dépendant de sa hiérarchie pour les validations (=retard)

État des lieux de la conception projet / produit

13

Méthodes agiles

Préparation demandées

● Découpage des lots de features en sprint et en fonction des livraisons des partenaires● Préparation des users stories pour le MVP● Préparation des technicals stories pour le MVP

Avantages

● Accélérer le « time to market »● Réactivité et ajustement possible tout au long du cycle de vie produit● Communication entre toute l’équipe● Méthode itérative● Cycle de vie plus long

Inconvénients

● Manque de documentation globale initiale● Parfois difficile de garder la vision globale et finale● Méthode nécessitant une bonne cohésion de l’équipe (responsabilité de chaque acteur)● Demande une grande disponibilité du product manager

État des lieux de la conception projet / produit

14

Grands principes des méthodes agiles

● Création dans les années 1970 dans l’industrie automobile notamment au Japon

● Décomposition du produit en versions / plusieurs versions forment une roadmap

● Décomposition des fonctionnalités du produit en stories (user ou technical)

● L’ensemble des stories forme le backlog du produit

● Principales méthodes agiles utilisées dans la conception informatique : SCRUM / KANBAN

● Ne pas appliquer bêtement une méthode mais l’adapter à la réalité de son entreprise (ex : pas de

développeur en interne)

15

SCRUM

16

VOCABULAIRE SCRUM

User-story ● Description d’une action d’un utilisateur en fonction de son rôle● Description des conditions d’acceptions de la story● Rédigée par le product owner

Technical-story ● Description d’une action technique● Rédigée par le lead developer

Task ● Permet de détailler chaque action à effectuer pour réaliser une story

17

VOCABULAIRE SCRUMBacklog ● Contient toutes les stories

(user et technical) du produit ● Permet de construire les

différents sprints

18

VOCABULAIRE SCRUMSprint ● Phase de développement d’environ 2 semaines (en fonction du MVP).

● Contient un certain nombre de stories déterminées lors du sprint definition.

● A la fin de chaque sprint, l’ensemble des fonctionnalités doivent être validées et deployées. Si ce n’est pas le cas alors on replace la story dans le backlog produit et on analyse la raison.

Story points ● Permet de définir la complexité d’une story ● Permet de générer le graphique de burndown● Échelle définie en fonction des équipes (1,3,5)

19

VOCABULAIRE SCRUM

Burndown Chart Permet de suivre visuellement l’avancement du sprint et d’alerter l’équipe

20

SCRUM

21

RITUELS SCRUMSprint définition

● Préparation des stories du sprint en cours

● Rédaction des tâches des stories

● Définition des points de complexité de la story (entre 1 et 5)

Daily scrum

● Qu’est-ce que j’ai fais hier

● Qu’est-ce que je fais aujourd’hui ?

● Est-ce que j’ai rencontré un point bloquant ?

Rétrospective

● Retour sur le dernier sprint et sur ce que l’on peut améliorer pour le prochain sprint

Démonstration

● Présentation des stories par les développeurs ou par le product manager aux managers

● Présentation des stories aux utilisateurs 22

SUIVI SCRUM

23

RÔLES SCRUMProduct owner / manager

● responsable absolu du produit● gère la relation avec les utilisateurs● doit être le moteur pour faire avancer le produit (résolution des problèmes,

prises de décisions)

Scrum Master ● doit s’occuper du bon déroulement des sprints● doit trouver des solutions avec le produt owner● pas indispensable dans une équipe réduite

Developer (software engineer)

● s’occupe de développer les différents stories (users / technical)● responsable de la stabilité technique du produit

Designer ● s’occupe de concevoir l’interface avec le product owner● responsable de la cohérence de l’interface du produit

Manager ● doit avoir une vue globale sur l’avancement du produit (coût / risque) ● participe à la vision, mais il n’est pas responsable du produit final. ● consulté lors des démos. 24

SCRUM

Organisation equipe Scrum

25

EQUIPE SCRUM MK2

Product manager

Philippe ALBERT

Lead developper

Julien Dubois

Drupal developer

Yohan Tillier

Drupal developer

FlorianLe Brenn

Directrice Artistique

Marion Dorel

Graphiste

Laurent de Lacerda

Managers Exploitatio& groupe

26

La vision Produit

27

Construire des produits

● Approche résolution d’un problème

utilisateur

● Remettre l’utilisateur au coeur de l’

ensemble des processus

● Comprendre les enjeux business

● Construire des MVP* à chaque sprint, ce

dernier doit être déployé en

preproduction

*MVP = minimum viable product

28

Apparition d’un nouveau rôle : Product Manager

29

Product Manager

● Concentrer sur la résolution d’un problème

utilisateur

● Remettre l’utilisateur au coeur de l’ensemble des

processus

● Comprendre les enjeux business

● Entre le business, la technique et l’utilisateur

30

Concevoir

Produire

Mesurer

Apprendre

Déployer

COMMUNIQUER

VISION PRODUIT

31

COMMUNIQUER

32

CommuniquerAvec vos utilisateurs

● Créer une expérience autour de votre marque (exemple : MK2 avec les évènements : couverture en live /

fiche après évènement )

Lorsque vous rejoignez une entreprise :

● Passer du temps avec l’équipe de vente et l’équipe en charge de la relation client

● Répondre directement aux clients sur les réseaux sociaux et sur les forums

33

CommuniquerAvec votre équipe

● Être leader

● Écouter

● Transmettre son énergie

● Proposer des solutions

● Protéger son équipe des demandes parasites

● Travailler sa rhétorique

● Préparer ses réunions

Logistique :

● Organiser ses ateliers dans une salle au

calme

● Préparer un tableau blanc pour expliquer les

concepts et illustrer

Lorsque vous rejoignez une entreprise :

● Rencontrer chaque membre de l’équipe en entretien

individuel

● Demander aux membres de l’équipe : Comment puis-je

t’aider ?

● Passer du temps avec le responsable technique pour

comprendre l’architecture technique

● Ne pas vouloir tout changer dès son arrivée et prendre

le temps de gagner en crédibilité et d’écouter

● Documenter tout ce que je vous apprenez (procédure

/ accès)

● Installer votre machine (filtre email / instance du

produit)

● Créér des alertes sur les produits concurrents 34

CommuniquerAvec votre hiérarchie

● Gagner en autonomie

● Acquérir une liberté de prise de décisions

● Se libérer de sa hiérarchique pour la conception

● Travailler sa rhétorique (comprendre ce que la personne veut entendre)

● Préparer ses réunions dans une logique de présentation & validation pas de discussions sans fin…

● Savoir recentrer les discussions dans les réunions

● Mettez en valeur vos produits (utiliser des mockups / PlaceIt)

Lorsque vous rejoignez une entreprise :

● Définir des objectifs précis

● Demander une vision sur 6 mois / 12mois

35

CONCEVOIR

36

Concevoir

37

Concevoir● Identifier les fournisseurs de contenus (rédacteurs /

partenaires métiers)

● Identifier les services (plate-forme emailing / CRM)

● Rassembler les documentations (discuter avec les partenaires

pour comprendre leurs métiers)

● Prendre en compte les business modèles existants (exemple

publicité)

38

ConcevoirDéfinir les contenus

● Catégories

● Tags

● Contenus et informations fixes dans le temps (lieux / paramètres)

● Volume des contenus à créer ou à migrer

39

ConcevoirDéfinition des objets fonctionnels

● Champs

● Type de données (entier / texte court / texte long

Définir un modèle de données

● Interaction entre les objets

Relever les concepts avancées

● date

● langues

40

ConcevoirMessage d’interaction utilisateur

41

ConcevoirMessage d’interaction de partage

Exemple partage Fiche Film :

● Bouton “J’aime” ○ Espace “Ajouter un commentaire” + TITRE DU

FILM + l’URL de la fiche film + Affiche du film ● Twitter

○ J’aime TITRE du film + URL raccourcie de la fiche film + via @MK2cinema

● Google+○ Espace “Ajouter un commentaire” +TITRE DU

FILM + l’URL de la fiche film + Affiche du film

42

ConcevoirDéfinir les éléments clients

● PDF

● Email

○ Cycle accueil & de relance

○ Confirmation inscription / achat

43

Définir des éléments réutilisables

● Penser des modules réutilisables plusieurs

fois surl’interface

● Penser viewmode

● Penser templates - Ne pas designer

chaque page

Concevoir

44

Définir un guide de l’UI

● Typographie

● Couleur principales

● Titre

● Paragraphes

● Bouton

Concevoir

45

Penser différents usages en fonction des devices

● pas les mêmes besoins d’information en

mobilité que sur un ordinateur

Penser cohérence globale

Penser omnicanal (accéder à ses informations

depuis n’importe quel point de contact avec le

client)

Concevoir

46

Mettre en place des interfaces programmables

● Penser également à la consommation des

informations par des programmes

informatiques

● Penser à l’ouverture des données

Concevoir

Exemple : http://api.mk2.com/api/2.0/movie.json?released_start=2014-09-01T00:00:01&released_end=2014-10-07T23:59:59

47

ConcevoirDéfinir les rôles (utilisateurs types)

● utilisateur anonyme● utilisateur connecté● administrateur● rédacteur

Définir la matrice des droits

● un rédacteur peut ajouter un article mais pas le publier

Définir les users stories (toujours garder en tête la résolution d’un problème utilisateur)

● Exemple : En tant qu’utilisateur connecté, je peux consulter l’historique de mes réservations

Définir les technicals stories

● Exemple : Import des nouveaux films

48

Quelques outils :

Sketch

● Crayon et template

Wireframe :

● Balsamiq

● Axure

UI

● Sketch

● Patternry

Collaboration

● InvisionApp

Concevoir

49

PRODUIRE

50

ProduireOutils de suivi de production dans un contexte de méthode SCRUM :

● Permet de suivre au quotidien l’avancée du développement du produit

Solution en SAAS

Tableau blanc et post-it

51

ProduireDéveloppement backend

● Construction du coeur du produit

○ Définition de l’architecture base de données

○ Gestion des imports / exports de données

○ Manipulation des données (enregistrement / suppression)

Technologies :

Framework :

CMS :

52

ProduireDéveloppement frontend

● Gestion des interactions avec les utilisateurs

○ Présentation des données

○ Possible traitement des données (trier / sélectionner)

Technologies : Framework :

53

ProduireUI design

● Conception de l’interface utilisateur

○ Boutons d’action

○ Boutons de navigation

○ Header

○ Footer

○ Icones

○ Checkbox

Tendances :

● Flat design (IOS 7 / Windows 8)

54

DÉPLOYER

55

DéployerDéfinition de la roadmap

● Ensemble des stories qui seront déployés dans les futures

versions

Définition des versions de produits X.Y.Z

● X représente le numéro de version majeure

● Y représente le numéro de version mineure

● Z représente le numéro de version de correction rapide

Définition du changelog

● Fichier présentant tous les changements effectués dans une

version

● Utilisé pour communiquer avec les utilisateurs et en interne

Par convention le MVP est la version 1.0 (première version stable)

56

DéployerArchitecture des instances

local ● Installé sur la machine du developer / designer / product manager● permet de corriger / tester / vérifier

dev ● Installé sur un serveur distant ● permet de tester la compatibilité entre les stories développées

preproduction ● Installé sur un serveur distant avec la même architecture que pour la production● permet de valider les stories avec les utilisateurs beta-test et la hiérarchie

production ● Installé chez un hébergeur avec gestion infogérance (surveillance des serveurs)● permet de proposer le produit aux utilisateurs finaux

57

MesurerQuoi mesurer ?

● Comportements utilisateurs

● Tunnel de conversion

● ROI

Vérifier les données

● qualité

● quantité

Outils de mesure :

● Google Analytics

● Google Analytics Event tracking

● Google Webmaster tools

● Crazy egg

58

MesurerLogs

● Serveur web

● Serveur base de donnée

● Échanges avec les systèmes partenaires

État des serveurs

● Charge sur le serveur

59

ApprendreLa culture Data-Driven

● Mesurer les actions des internautes et pas seulement l’objectif final

● Se baser sur des chiffres pour prendre des décisions et construire ses arguments

● Ne pas avoir peur de s’être tromper de route

● Adopter une logique scientifique

● Exploiter les données de ventes pour construire des modèles de prédiction

Méthodes

● Définir des tableau de bord (KPI) et relever les chiffres chaque jour

● Définir une logique de relevé pertinente

● Définir des pistes d’améliorer

60

TechniqueComprendre les enjeux techniques

● Temps de chargement

● Volume de données en base

Comprendre les logiques techniques de

développements produits

● Automatiser les actions qui peuvent l’être

● Créer des scripts

● Utiliser des outils de déploiement

automatique

61

TechniqueMéthodes d’identification des problèmes techniques

● Garder son calme :-)

● Profiling

○ Vérifier le temps de chargement et de génération de chaque fonction du programme

● Dicotomie

○ Diviser le code en deux partie, supprimer une partie et voir si le bug est toujours présent et ainsi de

suite jusqu’à trouver l’origine du problème

62

TechniqueCommuniquer avec votre équipe de développeur

● Ne pas aller les voir en leur disant uniquement : “ça ne marche pas”

○ Faire gagner du temps en analysant l’origine du problème

○ Transmettre des données de tests

● Ne pas voir les développeur comme des ours qui codent toute la journée :-)

○ Ce ne sont pas de simples exécutants, ils doivent être intégrés dans la réflexion autour du produit

63

TechniqueSe familiariser avec les concepts de

développements

● séparation présentation & contenu

● séparation des couches applicatives

○ Model (récupère les données)

○ View (affiche les données)

○ Controller (manipule les données)

● versionning de fichiers

○ chaque état du contenu du fichier

est enregistré et on doit pouvoir

revenir sur cet état si on le

souhaite

64

TechniqueSe familiariser avec les outils & services de développements

Éditeur de texte :

● Sublime text

Versionning :

● GIT

● SVN

● GITHUB

Profiling coté serveur :

● Xdebug

Profiling coté client :

● Outils développeur de Chrome / Firefox65

TechniqueSe familiariser avec les environnements de développement

● Virtualisation

○ Permet d’installer un système d’exploitation

en créant une machine virtuelle

● UNIX

○ Terminal

○ Gestion des droits

● Environnement XAMP

○ Linux

○ Apache

○ Mysql

○ Php

66

Sources et veille● Producthunt.com

● Intercom.com

● Producttalk.org (Teresa Torres)

● Sidebar (newsletter)

● Groupes Linkedin

67

@PhilippeALBERT

hello@philippealbert.fr

Des questions ?Des retours ?