How to Think like a Product Manager
- 2. 2 Part One: How to discover great products by talking with users
- 3. 3 Three Steps to finding a great product! 1. Deeply understand the user’s current solution and pain 2. Find hacks, jobs to do and how they judge solutions 3. Effectively learn about your hypothesis through provocation Before the product exists you have to engage potential users and identify their needs.
- 4. 4 How to understand your users’ needs: • Begin with a clear sense of the solution you want to understand. Without focus you’re doing an informational interview. • Start at the beginning and go until the end. Starting where you think is best reflects your hypotheses and bias. • Get to the *big eyes* “Whew!” moment. Most people default to presenting that things are fine. Always push to find pain points: “And did that meet your goal?” “Was it done on time?” etc. • Be nothing less than an expert. If you can’t flawlessly describe the industry, day to day, mindset and needs of your user after an session you didn’t dig deep enough. Deeply understanding your potential clients pain requires of curiosity and empathy. There are always more good questions.
- 5. 5 • Find the “Job to do”. Consumers purchase products to serve a particular need. The “hire” products to solve something, and fire them if they don’t solve the problem. What is your user hiring products to solve? VincuExample: Old Mutual was paying for ElEmpleo not because it efficiently delivered candidates, but because it had enough volume to keep recruiters always busy. • Identify “Hacks” When there’s not a specific solution for a problems, user’s often employ hacks. They use a product in a way it wasn’t intended to solve their problem. Find when this is happening: your product can solve it seamlessly. VincuExample: Colfondos, line by line, copy and pastes thousands of cedula numbers into a shared excel to see if they’ve already interviewed a candidate. • How and when do they judge the solution? At what point in the value chain does the user judge the utility of the product? This can be surprising. Often, it can be at more than one point. VincuExample: Bayport judged our product almost exclusively on show up rate, because it turned out we were in the sales budget competing against cash prizes. Human centered design thinking provides important techniques for uncovering user needs ¡Group Activity! Everyone find a partner! We’re starting a company that wants to improve the commutes of Bogotanos. Using the techniques from this and the last slide, learn about your partners work commute. What are their pain points? We’ll do 5 minutes and then switch, which is an absurd amount of time but whatever.
- 6. 6 When trying out different product ideas, use these techniques: • Provoke the user! Propose products that represent the logical extreme of your solution. Make it super extreme! Don’t worry too much about feasibility for now, you’re just trying to assess need. • Have them force rank options. Out of four potential products, if they can only have one, which would it be? If they had to rank the four, how would they rank them? • Use price as a provocation “Would you pay $2.000.000 COP for this product next month?” Use provocations to effectively test product hypotheses. This works much better than asking “What do you think about X”
- 7. 7 Part Two: How to think like a product manager and build great products as a team.
- 8. 8 Iterating and improving an existing product is every bit as hard as starting a new product. The three steps to proposing product changes like a product manager! 1. Deeply understand the problem you’re trying to solve. 2. Identify an ideal solution 3. Scope a practical solution to implement
- 9. 9 Step One: What, exactly, is the problem? ¡How do add great product features! A three step process It’s important to clearly understand the problem. Solving a superficial problem, or the wrong problem, leads to a bloated product that will have to be refactored and fixed later. Questions that help build a good problem statement: • What specifically needs to be solved? • Why does the product currently fail at delivering on our value proposition? • Why are their expectations not met? • What are users’ misunderstandings? • Use the “five whys” tool to understand the root cause of the user’s problem. You may finish this stage and realize: there is no problem! Congrats, you avoided work now and later when you would have had to fix an unnecessary feature. ¡Group Activity! Are these good problem statements? “Clients receive candidates that don’t fit the profile.” “Companies can’t easily export the cédulas of candidates, which are important to see if they’ve already interviewed the person” “Companies don’t understand how Vincu pre-filters, so they input bad data”
- 10. 10 How’d we do? ¡Group Activity! Are these good problem statements? (A) “Clients receive candidates that don’t fit the profile.” (B) “Companies can’t easily export the cédulas of candidates, which are important to see if they’ve already interviewed the person” (C)“Companies don’t understand how Vincu pre-filters, so they input bad data” Example A: • This problem statement is way, way too broad. It has hundreds of contributing problems. Ten different people will come up with ten different solutions on totally different parts of the product. A problem like this should use the five whys to break it down and establish contributing problems that can be solved. Example B: • I’d argue this problem isn’t a problem! It’s doesn’t align with our core value proposition: sourcing the right candidates that clients can’t easily find currently. Bells and whistles that help recruitment ops don’t contribute to the core value proposition. Example C • This is a strong problem statement: it’s specific about what product concept clients don’t understand, and draws a connection to our value prop.
- 11. 11 It’s important to not jump to conclusions about what the right solution is. It is often the case that a minimal investment, five minutes of structured thinking, will lead to a better solution. Guiding questions for thinking of an ideal solution: • What is the simplest, most straightforward way to solve this? • What can be modified so the product clearly delivers on the VP? • What can be modified so the user experiences the product the way they expected to? • What are the key product concepts and how can those be clearly communicated? Step Two: What is the ideal solution? Common pit falls: • *Big eyes* “Oooo, we could do X!” The first idea you get excited about is usually not the best idea. Don’t get emotionally invested! • “We could do it this way, or the other way” Debating only two sides of a product question ad nauseum is a sign you haven’t structurally tackled the problem. • “We just have to add a quick explanation” Text explanations are needed because your product was too counter-intuitive in the first place. Also, people don’t read. Find a solution that doesn’t need an explanation at all. • Always thinking piecemeal leads to feature debt, always thinking ideal leads to scope creep.
- 12. 12 Step Three: How can this solution be implemented practically? Having a vision that can be easily implemented is crucial. In order to be easily implemented it must be practical, from a development and client standpoint. Guiding questions: • What would a solution that introduces no new key concepts look like? • With limited coding how can you solve for the problem? • With limited graphic design how would the solution look? • What would the solution practically look like? (Scope it, draw it, spec the functionality) • What would the minimalist solution look like? What would a solution that adds nothing new look like? ¡Group Activity! Problem statement: Candidates who apply to invitations rarely apply on the job board. Using the guiding questions from this and the last slide, what product features could we think of that solve this problem?
- 13. 13 Solution There are multiple great ways to solve this problem. The solution I developed was to automatically navigate candidates to the job board when they apply. This can be done at the moment Vincu confirms the application has been sent. Why does this work: • It aligns with what the user expects: a confirmation page. • It’s simple: it happens directly in the user application flow • It requires no independent CTA or conversion attempt. Users are passively left on the job board when they apply. The attractiveness of the jobs should do the rest of the work.
- 14. 14 A “spec” details the important features of a product component so it can be implemented. In should include: 1. An Objective Why are we building this? What's the goal? 2. Defined Functionality What should happen when the user clicks button A? What should happen when the user doesn’t fill in field B? These are like the rules of your feature. It’s a good idea to use user stories to describe product functionality, i.e. “Candidates on the job board filter job listings by city to find jobs near them”. 3. Clear Layout If you’re adding a feature to an existing product, you probably don't need a complete, beautiful graphic design. However, a wireframe or mock up that shows the look and feel, and general layout is extremely useful. This communicates the feature much more effectively than a detailed description in text. 4. Final Copy It’s important to spec every word of text. Titles, subtitles, captions, helper text, alert text, button text, etc. If you’re not writing in your native language, always vet text with a native speaker (thanks Lina ). Follow these four steps and you will avoid immeasurable developer ridicule. How to create a practical product spec that developers won’t make fun of you for.
- 15. 15 The cultural divide between developers and business side people starts here. I bet every single one of us has had this moment: Ben’s theory on the origins of the developer/business cultural divide. Business person Developer I have a super difficult business/marketing/client problem! Hmmm, let me look into that for you Hey I fixed the issue 5 minutes later You practice black magic and can solve all my problems
- 16. 16 Issue 1) Storing or hosting a new type of information 2) Modifying how we store data, and migrating old data to the new format 3) There’s shared code between product features 4) Integrating our platform with a 3rd party app (PayU, FB, LinkedIn) 5) Out stack or 3rd party code we use doesn’t like the feature (Ember, Flask, open source code) How to avoid the “but it’s just a button!” moment. Learn to predict if your product feature requires a ton of coding work Why it’s harder than you think • Storing and hosting new types of information means creating or modifying a table in the data base. It might also require integrating with a hosting solution (like for hosting photos). • Migrations suck. It’s meticulous, tedious work to align all the data so it can be converted from it’s current state to a new state. Business concerns also come into play. • Often, different parts of the product share code. For example, inboxes and job posts at Vincu share lots of backend code. This creates interdependencies when one is modified. • This is obvious maybe, but linking with a 3rd party app requires lots of detailed work understanding the API, testing and getting it to place nice under many use cases. • This is technical, but some things are just hard because our code framework is the way it is. So congrats, you’re now aware of something you can’t predict :)
- 17. 17 Some instances when your item might be really easy: • We already use/have code that achieves the functionality you want • Your functionality doesn’t require that the output look beautiful/have flawless design • There’s plug ‘n play open source code that solves your functionality. • It’s just an easy item given the data/product we have! (Yay for non-answer answers!) Of course… The opposite can also be true! Your feature might be ridiculously easy. Empathy and learning is the key. ...and don’t forget, we live in an era when there is lots of software that can solve our problems without requiring code (lucky us!). Zapier, GoSquared, MailChimp, Metabase can often get you 50% -100% of the way there.
- 18. 18 Appendix: Good and bad mock ups, user flows, and other examples
- 19. 19 This is how not to make a spec. It’s way too detailed and convoluted. It has no visual component. Terrible. Appendix: Mock ups, wireframes, specs
- 20. 20 This is an ok way to wireframe a form using a Google Drawing, which everyone has access to (Though it’s strange that it’s broken up the way it is). It should include a spec per field that details functionality.
- 21. 21 Here’s a nice Balsamiq mockup of a pricing page and confirmation page. Scoping text in a mockup is a nice way to see how concise you need to be.
- 22. 22 This is an example of a basic user flow. You can use this to measure what % of users take which paths and where you need to optimize. This is pretty basic.
- 23. 23 Here’s a good example of a MECE product outline. With the product goals in mind, you can isolate how the product might solve for each of them and get clarity on product direction.
- 24. 24 This product component mock up shows how you might mock up something as simple as a button to show how it would work. This mock up shows the layout and position of different data point in visual product component: a job post. Balsamiq allows you to convey layout without flawless design.
- 25. 25 Here’s a professionally designed mock up done by Miguel of the job listing page. It’s important a mock up like this comes with a functionality spec: what happens if the user moves the slider in the upper right?