More Related Content

Slideshows for you(20)


Product Management Class for Digital Startups

  1. Product Management
  2. Protect Your Company
  3. Product managers are the glue that holds everybody in the company together — business, builders and customers. A product manager is a guard with a T-shaped profile, that creates common ground in the company by gathering and sharing the right information.
  4. GUARD
  5. The main groups to protect are your customers, builders and business — from each other. Everybody in your company has different goals and expectations. To make that work, you need to figure out what each group wants and how they can succeed. Then you can help them align their goals, and help them reach their goals together (or help them change their minds).
  7. To be able to fulfil that role as a guard, a t-shaped profile benefits you. The vertical bar | respresents your base, a solid foundation in management, for instance in a particular field like business, design or development. This base allows you to empathise, talk and connect with people. The horizontal bar — represents your knowledge and interest in development, design, business and other fields. You understand what drives your colleagues, and what they need.
  8. You have to understand why your developers need to refactor and why it might take a long time. You need to understand why your designer needs a ui kit. But you also need to understand why your company needs money now, and why you need to ship this feature now. And you need to understand your customers, be able to communicate with them and figure out why they are asking for those crazy features.
  10. Conclusion: you are the referee in your company, that makes sure everybody gets to make their goal in time. You enforce communication to keep the company in balance.
  12. Your Own Process
  13. To tackle this challenge I have some tricks for you, a process, that I learnt from making mistakes and other people’s mistakes. This process is not set in stone. I encourage you to make your own mistakes, and to find your own style. In this process, we focus on an iterative approach — one you adapt along the way to fit your company. It allows you to hold on to something, to start seeing patterns, where things went wrong and what went right.
  15. Let’s start with the beginning and go from there. Where do features come from?
  17. Find out what makes your customers tick, and what frustrates them. The focus here lies on quality, so make sure you talk to interesting and relevant people: your target audience. A quantitative survey will not help you here, but it can serve as a starting point, something to hold on to. Make sure you go deep enough, and don’t try to get the answers you want to hear. Not influencing your interviewee is harder than you think, it takes practice. Listen, and ask why.
  18. Why?
  19. Why?
  20. Why?
  21. The goal here is to get the conversation started. You can ask why again and again, until you forgot your initial question. As long as you get a good answer that helps you figure out what they really need.
  22. In the next phase, you can start card sorting. You gather the customer needs from your in-depth interviews, print them out and let members from your target audience sort the needs according to what they think is important.
  23. Take feature requests and input with a grain of salt. Let your interviewees inspire you, but do not lose track of your own vision.
  25. Interviewing a lot of people — and different types people is important. But finding the right ones is not easy. Expand and use your networking skills to the fullest. People that challenge you on a deep level are even harder to find. When you do find those people, keep them close to you in a customer advisory board. A Cab with 4 to 5 customers, can help you along the way.
  26. The people in your customer advisory board should be... • smarter than you • honest • visionaries • part of a brand you respect The quotes on your website will probably be theirs. • likeable You will be spending some time together... have a beer! • brave When times get harder, they can’t just run away.
  28. After your interviews, go and have some fun with your team. In this brainstorm, you are going to figure out which problems you can solve for your customers, based on the needs you discovered. Including colleagues makes them feel involved, and gives them a sense of ownership. Make sure you have different types of people in your brainstorm, for different points of view — for instance a developer, the CEO, a designer, a sales guy. But keep your brainstorm managable; 4 - 5 people is more than enough. To make sure the quiet but super smart colleague gets to say something too, you can ask people to prepare something during or before the brainstorm and share that with each other. And if somebody doesn’t want to join... Don’t force ‘m.
  29. There are different types of brainstorms, but you can really go Disney in this phase. Try to go beyond the obvious features, and challenge your team a bit. Tough crowd? You can always create a context where it feels more natural to go a step further.
  30. This brainstorm is based on a game called “The Extra Ordinaires Design Studio ”. They include a set of fictional characters that serve as potential customers for your product. I like creating my own characters. One of my favourite examples is the rusty robot that lives on planet Mars. He’s rusty, old, but has a heart for nature and tries to collect all the garbage he can find. Do you see a business model for him? Could he collect garbage from other planets? Are you the oil that can make him move quicker, or will you be the system that helps him communicate with other robots? It’s important to support each other in this craziness, and go on with “Yes, and...” instead of “no, because..” or “but”. Because you really want to step outside the box.
  31. personas
  32. An other type of brainstorm that gets the ideas flowing, is based on your target audience’s day. Create personas that represent your target audience in advance, so your brainstorm team knows who to think of. During the brainstorm, you explore how your product could be of service for your customer on different times of their day: in the morning, first thing at work, at a meeting, right before going to bed or when seriously bored. There are multiple possibilities. A few tips for your personas: please make your them relevant and easy to read. We do not care what your persona’s favourite color is. What we do care about, is how they would use your product and how you can make them happy. If you want more guidance, I have written a blogpost on how to create those personas (link to template in comments).
  34. feasiblenotfeasible(yet) usefulnot useful (yet)
  35. When you have a nice list of crazy ideas, you can start tearing them down. Take feasibility and usefulness into account, and pin down what you are going to build. This chart can help you figure that out — the top right represents the feature you want to be building, what’s left for you is to decide which ones you’re going to tackle first.
  36. personas
  37. If you are having a rough time deciding what feature goes first, go back to your personas. When you know what persona is most important to your company, and what feature is most important to that persona, you will know what to build first.
  39. Let’s start building. To help the team understand what the feature is and how to build it, you can create a feature spec. The spec includes information for different members of your team. Do not expect everybody to read it entirely, and do not have them create the spec themselves. You will visit your team members to gather information, evaluate and refine the feature spec, and you are going to write it. A spec supports you to make good decisions, and make it easy to iterate on your initial idea. (link to the template in comment)
  40. Write, Test & Rewrite
  41. Step 1: write the feature spec. Make sure you have the full story of your customer in mind: where are they coming from, what are their expectations, how are you going to help them complete their goals and do other features need to be adapted to make this one work better. Step 2: ask feedback from your stakeholders. Check if this is what for instance your CEO or co-founder had in mind when they thought up the feature. Rewrite where needed. Step 3: ask feedback from your customers. Show your plans, for instance mockups or a flowchart, to one or more relevant customers. One is better than none. Rewrite where needed. Step 4: ask feedback from your builders. Ask developers, designers, marketers) to check if they see any gaps, if you missed anything and if this is feasible. Rewrite where needed. Step 5: iterate until you are confident.
  42. Pro tips Make sure your feature spec is written in an easy-to-adapt format, so you will not waste time on editing. Some people like to use google docs or github pages, others like to make a whole website where they can include clickable prototypes. Investing some time in figuring out how to create a clickable prototype, is going to help you a lot in the future. Make them accessible to everyone at all times, and keep them in the same format so people will know where to look for what.
  43. Show your product, even when it’s not done. Feelings of shame disappear eventually. It can only improve your product!
  44. Test, Rinse & Repeat
  45. You are going to take these steps a couple of times, not necessarily in this order. Interview, brainstorm, select, prioritise, spec, test. You will get better at the process step by step, and you will be adapting your flow along the way. The same goes for your target audience: the more time you spend with your customers, the better you will know what they need. Keep your personas up to date. The most important part of the process, is feedback. Get as much feedback as you can, as early on in the process as possible, from anyone really. I do not care how you do it, show your product on a piece of paper for all I care, but do it.
  46. Staying in Control
  48. Big Bertha lists all of your features, to help you keep a bird’s-eye view on your product. She remembers who these features are built for (personas), the status of those features and what improvements you can make. Big Bertha is for your eyes only, because she only represents the present, and does not prioritise. Make her as extended, ugly or beautiful as you like. As long as you keep her alive — she will be your guide through the jungle.
  49. personas
  51. Big Bertha will make it easy for you to create a backlog. A backlog is a list of important features and bugs, maintained and prioritised by you. Some companies like to cluster features into user stories: a set of features that enable a persona / your business / a type of user to accomplish a goal. This user story is focused on the experience, and to make sure your features are delivered in a context, and not as a stand- alone feature. Other companies like to go really far and cluster these stories into epics — fulfilling a need of a user. Figure out what you need for your company, and find your own lingo and style. The backlog will be the fuel for your team. It needs to be accessible at all times, because this is where your colleagues will find their next mission.
  52. Letting Go of Control
  53. From here, you will have to let your features go. You have prepared everything as well as you could, received tons of criticism and feedback. It is your team’s responsibility now to bring your features to life. After your feature’s first baby steps, it will come back to you crying things are not working. You adjust some personas, do an other interview and maybe have a brainstorm, rewrite your feature specs, update Big Bertha and the Backlog: you iterate.
  54. A backlog is the fuel to your team’s engine. Assess & pick features every week.
  55. Chop the features up into bite-sized tasks or issues,
  56. To do Doing In review Blocked Done and start sprinting.
  57. Development Flow I’m still in control, see!
  58. GOALS
  59. This is where your team’s mission start. There are millions of ways to structure your development flow. Some people like scrum, others like agile. I do not care what you call it or what framework you use, but the trick is again to find your own flow.
  60. Goals: Control, Communication, Quality & Growth
  61. These are the main goals of a good development flow. Control A good flow, gives you control over time and output. It does not create more problems (duh!) but gets them out of the way. Communication Transparency towards team members and clients, manages expectations. A good flow facilitates communication on specific moments you agreed upon, without interrupting people on other times of the day. Quality & growth With a good flow, your team members can take responsibility for their work, which helps them improve themselves, and your product. Encourage autonomy. You want good team members to stick around. Create an environment they can thrive in — because there’s more to work than earning money.
  62. Product manager Builders Information loop
  63. You and your colleagues need to be able to communicate goals and expectations on a regular base. You collect that information, get the word out about what needs to be done and help them get it done. Product manager ∙ Gathers product goals from teams, investors & clients ∙ Prioritises tasks Builders ∙ Share what the team needs to execute tasks & do a good job
  65. This is an example of how you can structure, challenge an motivate your team. Feel free to research other types of development flows to see what works for your team — this is just the tip of the iceberg.
  66. Week 1 Sprint Week 2 Sprint Week 3 Sprint Week 4 Cooldown The 4-week Marathon
  67. I like to work with the terms Marathons and Sprints. The term marathon reminds you that you’re in it for the long haul, and the term sprints keep you focussed on getting things done. A marathon consists for example out of four weeks. The first three weeks are focussed on sprinting, the last week is meant for zooming out and cooling down. The marathon gives you control over your time, and focus on a steady pace to ensure quality.
  68. Marathon Preparation
  69. The preparation of a marathon happens in the cooldown week of the previous marathon. The product manager gathers information. The preparation of your marathon during cooldown week, allows you to communicate with your team members without bothering them while they are doing focussed and zoomed in work. ∙ Check Big Bertha & road map ∙ Consult all teams for bugs and requests ∙ Check team availability (holidays etc) ∙ Discuss & plan features in backlog for coming three weeks
  70. Sprint
  71. During the sprint weeks, your builders pick and assess features from the backlog. Preparation of a sprint week starts at the beginning of each sprint. The sprints help your team to decide what they are going to do and when, to take control over their own time. ∙ Pick features from marathon backlog for 80% of the week — leave some room for mistakes. If there’s time left, there’s always more in the backlog. ∙ Clarify what you need to get it done (what, when, who) ∙ Chop up features into clear, detailed issues & tasks ∙ Assess the features, and assign a colleague
  72. 1 3 85 2013 40 0∞ ? Scrum poker
  73. There are multiple ways to make estimates for these features, scrum poker is one of the examples that focuses on how hard it is, instead of how long it wil take. Research techniques to find out what fits your team. This will definitely fail the first couple of weeks: do not give up! It takes time and practice to master this valuable skill.
  74. To do Doing In review Blocked Done Every day communication
  75. During your sprint, make sure your colleagues know what you have been up to. Some people like 15 minute standups (in real life or via calls), others like to automate it with a system like Jira, Kanban Trello, Github issues or excel. Find your way to keep each other informed. The daily updates make communication easier and sure you know what your colleagues have been up to, and where they need help. 1. What did I do yesterday? 2. What am I doing today? 3. What do I need?
  76. Cooldown
  77. The cooldown allows your team to debrief, show & tell what they have accomplished in the previous weeks, and get up to speed with others. Share your stories with stakeholders and (future) clients. Have sales spice up their pitch. Cooling down allows you and your team to zoom out, correct mistakes, improve and refactor where needed. This is also an ideal moment to study a little, talk to a mentor or finish a project. The cooldown gives you and your team the time to assess your own ability and what you have accomplished — which focuses on quality and (personal) growth. The product manager gets the time to prepare for the next battle; a new marathon.
  78. Goals: Control, Communication, Quality & Growth
  79. This is one way to tackle your development flow. Get inspired, and do not lose track of the actual goals of your development flow. Practice and adapt, do not just throw away your efforts if your flow fails the first couple of weeks.
  80. The Road Map
  81. Q1 Q2 Q3 Q4
  82. A road map is a document that helps you to motivate your team, to convince investors and to get an idea of what you are doing. When you reach a milestone, it is an excuse to get out the champagne with your team. But it is not set in stone — a roadmap is based on ever changing things like ideas, money, big bertha and personas. So your roadmap will change accordingly. We can not see into the future, the further away the more vague it gets, so don't hold on too tight. You can base your roadmap on numbers like clients or money, on the personas you want to reach or the user stories you want to tell.
  83. Q1 Q2 Q3 Q4 10 customers 40 customers 20 customers 100 customers Customers
  84. Q1 Q2 Q3 Q4 € 32k MRR € 66 MRR€ 46 MRR € 99 MRR Monthly Recurring Revenue
  85. personas
  86. Q1 Q2 Q3 Q4 Napoleon LafawnduhKip Deb Personas
  87. A roadmap gives your team something to strive for. It fuels your marathons and your backlog. Share it every few months, but do not go waving it into people's faces every day. Your road map gives you a sense of direction, it is not a promise set in stone — because your company will change every day.
  88. Expectations designer frontender developer CEO sales
  89. Reality
  90. When doing this job, things will not always go as expected. Not only will your process not go in the right order, you also will not be able to complete all of the steps the way you wanted to. Have confidence, get up and try again. People will be looking at you when things go wrong, so you better toughen up and prepare for battle. You will get better at it, and find a flow that takes your company to the next level.
  91. Explore your comfort zone
  92. Protect Your Company
  93. My name is Miet, I’m a digital product designer.
  94. erci