Notes from the Standford Product Management Course Part One (Module 2-4)

Notes from the Standford Product Management Course Part One (Module 2-4) === [TOC] # [A Review of the Online Stanford Product Management Course](https://woodsey.medium.com/a-review-of-the-online-stanford-product-management-course-fe5eb5bea66c) The course is [Product Management: Transforming Opportunities into Great Products](https://online.stanford.edu/courses/xprodmgt110-product-management-transforming-opportunities-great-products) # Module 2: Overview of the Product Lifecycle ## [Be a Great Product Leader](https://adamnash.blog/2011/12/16/be-a-great-product-leader/) - Responsible for just 3 things Strategy, Prioritization & Execution. - Product Strategy - articulate two simple things: What game are we playing? How do we keep score? - Clearly describing the game your playing and the metrics you use to judge success allows the team, independent of the product manager, to sort through different ideas and decide which ones are worth acting on. - Clearly defining what game you are playing includes your vision for the product, the value you provide your customer, and your differentiated advantage over competitors. More importantly, however, is that it clearly articulates the way that your team is going to win in the market. Assuming you pick your metrics appropriately, everyone on the team should have a clear idea of what winning means. - You should be able to ask any product manager who has been on the job for two weeks these questions, and get not just a crisp, but a compelling answer to these two questions. - Prioritization - The question isn’t what is the best list of ideas you can come up with for the business – the question is what are the next three things the team is going to execute on and nail. - Phasing is a crucial part of any entrepreneurial endeavor – most products and companies fail not for lack of great ideas, but based on mistaking which ones are critical to execute on first, and which can wait until later. - Execution - Product specification – the necessary level of detail to ensure clarity about what the team is building. - Edge case decisions – very often, unexpected and complicated edge cases come up. Typically, the product manager is on the line to quickly triage those decisions for potentially ramifications to other parts of the product. - Project management – there are always expectations for time / benefit trade-offs with any feature. A lot of these calls end up being forced during a production cycle, and the product manager has to be a couple steps ahead of potential issues to ensure that the final product strikes the right balance of time to market and success in the market. - Analytics – in the end, the team largely depends on the product manager to have run the numbers, and have the detail on what pieces of the feature are critical to hitting the goals for the feature. They also expect the product manager to have a deep understanding of the performance of existing features (and competitor features), if any. ## [Do Product Managers really need a background in CS?](https://theartofproductmanagement.quora.com/Do-Product-Managers-really-need-a-background-in-CS) - Here’s the simple answer: Many people without a background in computer science can’t form a strong working relationship with engineers. - All of those excellent product management skills will go to waste if the PM alienates his engineers and can’t earn their respect. Product Management is a job where you have to lead without authority. The only way to get great work done is to bring the team onboard with your vision. ## [Product Visionary vs. Product Leader](https://caseyaccidental.com/product-visionary-vs-product-leader/amp/) - Product Leadership: It’s about helping everyone understand what the vision and strategy is. It’s about communicating to the entire team why the company is doing what it is doing. It’s about building a process that helps a team execute on that vision. It’s about when there are competing visions, aligning and motivating the team to focus on one, and getting people to disagree and commit (including sometimes yourself). It’s about looking at data to measure if product changes are having a positive impact on the customer and the company’s growth. It’s about talking to users to understand why they’re doing what they’re doing, and the problems they still face even though your product exists. It’s about mentoring more junior people on your team, across product as well as engineering, design, and analytics. And they don’t have to listen to you, so you have to use influence rather than authority to be successful. ## [Ode to a Non-Technical Product Manager](https://hunterwalk.medium.com/ode-to-a-non-technical-product-manager-7776efb98acd) 1. Be technically curious — forget writing production code but knowing how things work and even being able to prototype is great. 2. Develop specific superpowers — don’t just rely on being a smart generalist. 3. Focus on making your team better — your success is tied to theirs, what do you need to do to help? ## [Leading Cross-functional Teams: Always bring the donuts](https://speakerdeck.com/kennethn/leading-cross-functional-teams-and-the-product-manager) - Communicating - Never tell people how to do things. Tell them what to do and you'll be surprised by their ingenuity - Communicate to different people in their own language - Represent the points of view of people not in the room - How to earn respect from engineers - clear obstacles - always take the blame - ask smart questions - explain the 'why' - empathize - bring the donuts - How to earn respect from Sales - know their number - get on the phone with their customers - make promises so they don't have to - help them be creative - bring the donuts - How to earn respect from executives - have a vision - be patient - know your competition - make your commitments - bring the donuts - How to earn respect from customers - understand what they want - call them out of the blue - keep your promises - take the blame - bring the donuts - Time management: ask engineers "what needs to happen for you to finish and how can I help?" - Likely estimate - Pessimistic estimate - Optimistic estimate - (O + L*4 + P)/6 - also, never assume more than 5h of developer progress a day ## [A Product Manager’s Job](https://joshelman.medium.com/a-product-managers-job-63c09a43d0ec) - Help your team (and company) ship the right product to your users - Help your team - (a) coordination — ensuring that the team is planning, making decisions, and working together effectively with a clear purpose and focus, and - (b) communication — making sure everyone understands what is happening, when, and why, especially as things inevitably change. - More tactically,helping your team often means being the person who writes and summarizes notes after a long meeting, or writing a spec to make sure you have captured the team’s consensus and plan in written form. - Help your company - that they should be able to translate their ideas back to the core vision and goals of the company, and ensure they have top-down support for executing on them - Ship - Great product managers understand the very tricky balance between getting it right and getting it out the door. Teams should always be testing, trying out the products, and listening to early feedback, but at some point in every project, the team has to make a call that the product is ready enough - the right product - Great product managers have a good feel for what seems right or wrong, and are also good at listening to early feedback from testers and others who try it. They are good at getting a sense from the founders and other leaders to make sure the product feels right. - for your users - The best product managers are the advocates for your users and represent users in nearly every conversation when making decisions about the product. - Doing this requires a deep understanding of your target users, what their challenges and issues are, and how your product should deliver the value and delight they are looking for. Great product managers listen to user feedback all the time — whether it’s from usability tests, meeting users in the field, reading support emails or tweets, or working with the people in your company who do all of those things on a daily basis. ## [What Product Management Is Not](https://svpg.com/what-product-management-is-not/) - Product Management is not defining the business case - In many organizations the product manager does put the business case together, or at least contributes to creating the case, and this is fine, but don’t confuse this with the product management job. - Product Management is not defining market requirements - The product manager creates an MRD (Market Requirements Document) that enumerates what the product manager thinks the market is looking for, and then actually defining the product that meets these requirements is an exercise left to the reader (which is typically an engineer). - The first is the fallacy of so-called “market requirements.” Markets don’t have requirements. People do. And the person that’s actually going to be defining this product has got to talk to these people directly. - The second issue is the fallacy of market requirements separate from product requirements. The whole idea is to discover a product-market fit and this requires a deep understanding of both the market needs and the technology’s capabilities. It is during the discovery process that you identify true market requirements and technical solutions that successfully address these requirements. - Product Management is not requirements gathering - True product companies know that customers have issues that need to be addressed, but they are not in a position to dictate the product requirements. In other words, you can’t make the mistake of confusing a customer requirement with a product requirement. - Be wary of anything that encourages this “requirements capture” or “requirements management” mentality - Product Management is not project management - In this model, the product manager is considered the person to collect and document the requirements, and manage the project from conception to delivery. But the discovery process is not simply a task in a project plan. It is its own process, which is very different than the product development process. - Product Management is not product marketing - Finally, product management is not about pricing, promotions, positioning and messaging, or product launch activities. - While the company might be tempted to ask the product manager to cover these responsibilities as well, realize that the nature of these marketing-based activities is dramatically different than the discovery-based activities, and it’s very hard to find people that are skilled at both. ## [Product Manager You Are… a janitor, essentially.](https://medium.com/all-things-product-management/product-manager-you-are-664d83ee702e) - The majority of PM jobs involve you driving forward some relatively small dimension of the product, with little meaningful control over resourcing, zero actual reporting authority over anyone, nor much, if any, say in the budgeting process—all within the confines of some larger organizational superstructure that you are subject to, rather than master of. - You're a coach. The coach knows which players to put into which situations, understands how people work together, intuits which plays to call in the crucial moments. But perhaps most important is the role a coach plays as motivator. Coaches understand that teams are composed of people and the interpersonal relationships between each member determine to a large extent the effectiveness of the team, what it is capable of producing as a unit. - You're culturally engineer. In this sense, the best PMs are culturally engineers: you have the DNA of a hacker, you get XKCD humor, you have a favorite programming language, your standards of fashion are low, you feel the pain of server outages, you can draw boxes and arrows with the best of them, and you’re just close enough to the metal to know that stuff doesn’t happen by magic alone. - You're a hammer. Somewhat similarly, as a PM, your chief stock in trade is influence. You live and you die based on your ability to convince other people to do what you need them to do for the good of the product. - You're a janitor. More generally, you need to be the force that makes things happen. You don’t let people equivocate; you make people commit to a clear position and establish course of action. You drive to resolution. You don’t let loose ends stay loose and you prevent things from falling through cracks. You are the propellant that pushes through all opposition and ultimately gets the product shipped. - You're a router. Whether it be in the form of bugs/tickets, emails, in-person meetings, phone calls, video conferences—as PM you’re constantly going to be overwhelmed with information and questions, much of which require at minimum your attention, if not intervention of some kind. More often than not, however, you’re not actually the best person to take action. And so a lot of what you do is act as “traffic cop” and route things to the right place. - You're a super user. A PM who is constantly reporting bugs is a PM who gains credibility with the engineering team as someone who is passionate, detail-oriented and cares about quality. Also, in using the product out there in the World, you get to see how others react to the product and better understand the social context in which people will use and interact with the stuff you’re building. - You're an inventor. o great PMs are usually creative types, who can generate and churn through many ideas all at once, to think on their feet and arrive at solutions to difficult and multi-faceted problems. Every day you will find yourself needing to invent. Fortunately, you will rarely lack in ideas from those around you; in fact your team will be a source of far more creative thought that you alone can produce. - You're a ghost. A good way to approach this is to let people and problems come to you; if the ship is running smoothly there’s no need to spin the wheel just because it’s in your hands. So whenever possible, try to get out of people’s way and instead make yourself just available enough that as soon as you’re needed you can materialize into existence and be helpful. - You're the product. The product your team builds and ships is the most faithful representation of your success as a PM. It is the thing from which you cannot hide. It is your legacy. It is quite literally the sum product of all of your effort, every single decision made along the way. ## [The Bipolar Nature of Product Management](https://medium.com/@johnv/the-bipolar-nature-of-product-management-6c534479d2e9) Strategic vs Execution Focused Strategic - A product manager must be able to see the big picture. - He or she must have a strong understanding of where the market, the business, and where their particular product will be in 12–18 months. - They must have some plan or roadmap on how they are going to get there. - The ability to articulate their strategy well and get stakeholders to buy in cannot be overstated. - Strategic thinking cannot be a side project done in between meetings, in the shower and on the commute. - Time must be made for big-picture thinking and planning Execution - Conversely, a product manager must be able to execute and thrive within the world of details. - Every backlog needs prioritization. - Every design treatment requires specific feedback. Every sprint demands good stories. - Every a/b test necessitates deep analysis. Every standup brings to light a product nuance that needs clarity and unblocking. - The product manager must have command of the details and be ready to dig in at any moment. - It’s the only way progress can be made. Convergent vs Divergent - Product managers must facilitate and encourage thinking that is outside the lines. - They must separate these “jam sessions” in name and form from normal execution-focused conversations. Anything is possible in these conversations. - In fact most of the ideas should never, never happen. But, if you don’t explore all the possibilities, no matter how crazy, your product’s potential is seriously reduced. - At some point you need to stop talking cray cray and things need to get shipped. - Big ideas need to get refined into specifications, wireframes, visual designs, stories, sprints and what have you. - Additionally, the product manager needs to understand the capabilities of the team, the effort involved in bringing an idea to life, the impact it will have on key metrics, and the varying business needs. - They need to have the ability to converge on a plan, rally others around that plan, and execute it with strength. Consensus building vs making hard calls - Product managers work with designers, UXers, developers, researchers, data scientists and cross-functional stakeholders. - And, guess what? None of those people are on the Product Management team. - The PM has no direct organizational authority over those people. - This means if they want people to do their best work they need to engage and inspire them. - The PM needs to influence others because they have little authority. However, they must resist being manipulative for this is the dark side of influence. - They need to develop strong relationships, make compromises, give a ton of context, and most of all create a sense of shared ownership over most decisions. Bring the donuts vs ruthless management of time - the product manager must do whatever it takes to help the team ship the product. - This might mean taking notes at a meeting, testing the product, messing with Hangouts and the projector for 15 minutes so that the meeting can start, or it might mean bringing donuts for the team. - The product manager might be the “CEO” of the product but they are also the janitor (no offense to janitors). No task should be below the product manager. - “How can I help?” should be coming out of the PM’s mouth all the time. ## [Good Product Manager/Bad Product Manager](https://a16z.com/2012/06/15/good-product-managerbad-product-manager/) - Good product managers know the market, the product, the product line and the competition extremely well and operate from a strong basis of knowledge and confidence. - A good product manager is the CEO of the product. - A good product manager takes full responsibility and measures themselves in terms of the success of the product. - The are responsible for right product/right time and all that entails. - A good product manager knows the context going in (the company, our revenue funding, competition, etc.), and they take responsibility for devising and executing a winning plan (no excuses). - **Good product managers don’t get all of their time sucked up by the various organizations that must work together to deliver right product right time.** - Good product managers are the marketing counterpart of the engineering manager. - Good product managers crisply define the target, the “what” (as opposed to the how) and manage the delivery of the “what.” - Good product managers communicate crisply to engineering in writing as well as verbally. - Good product managers don’t give direction informally. - Good product managers gather information informally. - Good product managers create leveragable collateral, FAQs, presentations, white papers. - **Good product managers anticipate the serious product flaws and build real solutions.** - **Good product managers take written positions on important issues (competitive silver bullets, tough architectural choices, tough product decisions, markets to attack or yield).** - **Good product managers focus the team on revenue and customers** - Good product managers define good products that can be executed with a strong effort. - Good product managers think in terms of delivering superior value to the market place during inbound planning and achieving market share and revenue goals during outbound. - Good product managers decompose problems. - Good product managers think about the story they want written by the press. - Good product managers assume press and analyst people are really smart. - Good product managers err on the side of clarity vs. explaining the obvious - **Good product managers define their job and their success.** - **Good product managers send their status reports in on time every week, because they are disciplined.** # Module 3: Understanding the Problem Space ## [Start Talking! How To Do Customer Interviews That Reveal Priceless Insights](https://www.crazyegg.com/blog/start-talking/) Your interview should not feel like an interview at all. It should feel like a conversation. Revenue coach and veteran marketer Kristin Zhivago, author of Roadmap To Revenue, says chatting to those who have already purchased helps you “reverse engineer” a successful sale. “They [customers] have plenty to say about how you presented yourself, what actually happened, what they wish would have happened, what the tradeoffs were in their minds as they were considering you, why they bought from you after all, and what they are now telling others about you. Yep, that’s priceless stuff, stuff that sends you running in the RIGHT direction.” Shoot for about 5 people per customer category or persona — but no more than a dozen. After five or six interviews, you’ll likely start to see trends and themes emerging in the responses. That means you should have a list of questions handy, but don’t stick to the script. Your No.1 job as an interviewer is to listen and occasionally ask ‘probing’ questions to get more insight or to gently steer the conversation where you need it to go (we’ll get to this stuff shortly). Here are some topics you may want to cover: * Asking about motivations: What was going on that made you seek out our software? * Asking about problems & struggling moments: Tell me about when you were trying to write your business plan? What was that like? * Asking about the value they receive from your product: Exactly what does our software help you do? But the most insightful responses — especially for copywriting and messaging — will often come from asking your customer how they feel. * What were you feeling while using the product? * When you found our solution, how did that make you feel? * What were you feeling when you decided to switch to us? Avoid * Leading questions * Asking why as they will end up using their rational mind instead Importance of three things: * Building rapport with customers (to establish trust so they open up) - make sure you're both on the same page - start with easy, fact-based questions - show genuine interest in what they have to say - mirror how they speak * Practicing effective listening (to really absorb what they’re saying) - reflective listening such as paraphrasing what they said - control your visceral reactions - probing questions * Asking “probing questions” (to get deeper insight on what they’re thinking and feeling) - ask for more specifics - embrace awkward silences, sometimes people might blabber to try fill it - use the echo probe where you repeat the last thing they said and probe them to go on ## [Jurassic Park: How P&G Brought Febreze Back to Life](https://www.forbes.com/sites/petercohan/2012/02/19/jurassic-park-how-pg-brought-febreze-back-to-life/?sh=7c8863627f6d) Whenever you need to back out of the garage after that, you go through a three stage process: cue -- something that triggers the habit; routine -- where you instinctively perform the habitual activities; and reward -- where you get some pleasant outcome as a result of performing the routine. What P&G discovered -- after a failure from which it learned -- was that its original approach to marketing Febreze was wrong because that approach required consumers to change their habits. When P&G ultimately discovered a way to make Febreze part of an existing routine, sales exploded. It included the cue -- a freshly cleaned room; the routine-- spraying that room with Febreze; and the reward -- relishing "a smell that says you’ve done a great job." Within two months of the summer 1998 marketing revamp, Febreze sales doubled. By 1999, Febreze revenues totaled $230 million. Since then Febreze has introduced spinoffs that account for over $1 billion in annual sales. ## [How do Customer Development and Product Management fit together? (2014)](https://www.cindyalvarez.com/how-do-customer-development-and-product-management-fit-together-2014/) * Customer development isn’t usability testing, or focus groups, or dutifully recording “voice of the customer” suggestions and putting them into a backlog. * Those are all activities that people do to maintain the status quo. Customer development is a risk mitigation tool. * A perfectly acceptable outcome of customer development is to decide not to build that product or decide not to sell to those customers. Customer development and product management are two complementary tools. Used together, they provide a competitive advantage to any products company. Customer development is not the secret to creating a great product. You start customer development with a hypothesis, which you are trying your damnedest to disprove. At this point, we move into what most of us have traditionally known as product management – envisioning requirements, prioritizing, identifying constraints, pricing, working with engineers to get the thing built. ## [The power of observation: How companies can have more ‘aha’ moments](https://gigaom.com/2012/09/15/not-enough-time-to-save-time-the-value-of-rapid-ethnography/) And in all my experience doing ethnography, I’ve yet to work on a project that didn’t have at least two of these outcomes: * Steered the project away from an unproductive direction * Refocused the project toward solving a clear, demonstrated problem * Opened management’s eyes to problems or patterns that had been hidden to them, sometimes with simple solutions * Inspired technology ideas that could solve an observed problem in a new way Since I am trained primarily as a user experience designer and secondarily as an ethnographer, I looked for obstacles that the officers were putting up with without even noticing and ways they worked around the system to accomplish their goals. Those practices tend to spark ideas about technology solutions that could help people remove or reduce inefficiencies. One of the key findings was that, in the city that already had sensors installed in the parking spaces, the PEO and supervisors were finding the system extremely frustrating and felt that it was reducing rather than improving their productivity. I observed the officer as she chased down one “violation” after another only to find that the car had a handicapped placard, or the person had already paid, or there was no car in the parking spot. A key benefit of watching what happens “in real life” is that it can uncover practices that shift the clients’ thinking about which problem to solve and how to solve it. For example, our client was surprised to hear about these difficulties with the sensor-based system. And it became clear that if a system with sensors in the street was creating such frustration and inefficiency, it was even less likely that a system based on probabilities from historical data would be successful. ## [12 Tips for Early Customer Development Interviews (Revision 3)](http://giffconstable.com/2012/12/12-tips-for-early-customer-development-interviews-revision-3/) 1. One person at a time - Personally, I tend to do one-on-one interviews because I think people loosen up and thus open up a bit more, but it can be nice to have a note-taker, which allows you to focus entirely on the conversation and body language. 2. Know your goals and questions ahead of time - Have your assumptions and thus learning goals prioritized ahead of time. Decide who you want to talk to (age, gender, location, profession/industry, affluence, etc) 3. Separate behavior and feedback in discussion - Decide up front if your focus is going to be on learning a user’s behavior and mindset, and/or getting direct feedback or usability insights on a product or mockup. 4. Get psyched to hear things you don’t want to hear - If you don’t do this, you might find yourself selling or convincing, or even hearing what you want to hear. 5. Disarm “politeness” training - People are trained not to call your baby ugly. You need to make them feel safe to do this. Ask them up-front to be brutally honest, and that this is the very best way they can help you. 6. Ask open ended questions - Do not ask too many yes/no questions. Sometimes it is hard not to ask a yes/no question, but always follow up with an open-ended question like “why?” or “tell me more about that experience.” 7. Focus on actual behavior, not speculative or abstract feelings - People *love* to talk about features and solutions. When you are in learning mode, don’t let that dominate the conversation. Try to keep things factual. Get them to tell you stories about how they previously experienced a problem, if they tried to solve it (or why not), and what happened. 8. Listen, don’t talk - Try to shut up as much as possible. Don’t rush to fill the “space” when the customer pauses, because they might be thinking or have more to say. Make sure you are learning, not selling! 9. Follow your nose and drill down - Anytime something tweaks your antenna, drill down with follow up questions. Don’t be afraid to ask for clarifications and the “why” behind the “what”. 10. Parrot back or misrepresent to confirm - For important topics, try repeating back what the person said. You can occasionally get one of two interesting results through this. In the first, they correct you because you’ve misinterpreted what they said. In the second, by hearing their own thoughts, they’ll actually realize that their true opinion is slightly different, and they will give you a second, more sophisticated answer. 11. Ask for introductions - At the end of every interview, see if you can get leads to another 1 to 3 people to talk to. 12. Write up your notes as quickly as possible - The details behind a conversation fade fast, so if you haven’t recorded the session, write up your notes and color commentary as soon as you can. ## [Five Whys](http://www.startuplessonslearned.com/2008/11/five-whys.html) I have come to believe that this technique should be used for all kinds of defects, not just site outages. Each time, we use the defect as an opportunity to find out what's wrong with our process, and make a small adjustment. By continuously adjusting, we eventually build up a robust series of defenses that prevent problems from happening. It's important to remember the proportional investment part of the rule above. It's easy to decide that when something goes wrong, a complete ground-up rewrite is needed. It's part of our tendency to over-focus on the technical and to over-react to problems. Five whys helps us keep our cool. If you have a severe problem, like a site outage, that costs your company tons of money or causes lots of person-hours of debugging, go ahead and allocate about that same number of person-hours or dollars to the solution. But always have a maximum, and always have a minimum. Start by having a single person be the five whys master. This person will run the post mortem whenever anyone on the team identifies a problem. Don't let them do it by themselves; it's important to get everyone who was involved with the problem (including those who diagnosed or debugged it) into a room together. Have the five why master lead the discussion, but they should have the power to assign responsibility for the solution to anyone in the room. Once that responsibility has been assigned, have that new person email the whole company with the results of the analysis. This last step is difficult, but I think it's very helpful. Five whys should read like plain English. If they don't, you're probably obfuscating the real problem. The advantage of sharing this information widely is that it gives everyone insight into the kinds of problems the team is facing, but also insight into how those problems are being tackled. And if the analysis is airtight, it makes it pretty easy for everyone to understand why the team is taking some time out to invest in problem prevention instead of new features. ## [How to Listen to Customers How do you hone in on what users really need?](https://www.bringthedonuts.com/essays/how-to-listen-to-customers.html) It’s not that users are lying (usually), it’s just that they don’t know what they want when they don’t know what’s possible. Influencers - Influencers have an intuitive handle on what other hipsters get excited about, and what they hate. They talk to lots of people, read a lot and try a lot of things. The most important asset they offer is preventing you from committing a serious faux pas that could kill your product. They can also give you an early warning of competitive products or companies that might be relevant. And unlike most customers, they’re usually brutally honest. Influencers like to run with the crowd so you need to know how to balance the feverish, often polarizing reception you’ll get (“it rules!” or “it sucks!”). Early adopters - Listening carefully to your early adopters can serve as an early warning system for what the majority of users will want in the future. The problems they’re having are problems everyone will have. When a power user describes a problem they’re encountering in your product, you can bet a lot of other users will come across it at some point. Leading adopters also understand your product deeply, and can describe what they want in richer detail, using the terminology you’re familiar with and the capabilities of your product as background. Many companies have been lured to their doom by a very small, well-meaning and vocal group of power users who fooled the company into thinking they were gaining real traction. Also, power users rarely describe a problem, they usually ask for a specific solution. Since they understand the product so well, they prefer to speak in features, which can mask the underlying problem. Middle adopters - The majority of your users probably fall into this category, but be careful to lump them into a pile - they’re far too diverse. The fact is, these folks are your most valuable asset from a product development perspective. They’re also the ones paying the bills. You get the most out of them when you get them talking about pain - what is painful about what they’re doing today and what would help eliminate the pain. Middle adopters need interactive dialog. They won’t just start talking unaided like the influencers or the early adopters, so you need to bring them out with lots of open questions and “what ifs”. Rule - when a middle adopter user starts apologizing, it’s your fault. Since these customers aren’t as comfortable or familiar with technology, getting to the real problem can sometimes feel like an archaeological dig. But keep at it. Late adopters - Are they fearful or just skeptical? Late adopters are the sanity filter for your customer research. As product developers, we are great at convincing ourselves of the royal ineptitude of the incumbent solution and the absolute withering pain under which our soon-to-be-freed subjects stand to be liberated. Nothing like a conversation with a late adopter to throw cold water on that. They know what they like about what they have today, but they’re not as good at articulating what they’ll need tomorrow. ## [How to find early adopters](https://brantcooper.com/brants-rant/how-to-find-early-adopters/) Step 1. Profile your Customer Write up a description of your ideal mainstream customer. Re-read your description and remove attributes that are not unique. In other words, if they are male or female, then their sex is not a differentiating characteristic. Step 2. Brainstorm Locale Brainstorm how to reach these users. To state the obvious, users who are not active online, are not likely to be reached online. This is the whole point of “getting out of the building.” Don’t build an online strategy for reaching offline users. Initially, the idea is to cast a wide net, because you really don’t know the best place to find your prospective customers. There are no wrong methods, if the end result are users who understand the problem you’re trying to solve. Models are only that. There are no rules, only methods to acquiring answers from the customer. Step 3. Who determines how Your endgame is an interview. You want to speak to your customers in order to confirm your assumptions about their need for your product. You’re not selling, you’re listening. You are not gathering feature requirements, you are gathering understanding of their pain. You must learn: * is problem assumption valid * are current solutions insufficient * does your solution sound plausible * is the person I’m speaking with a potential early adopter Step 4. Identifying the early adopters Simply put, early adopters have these three determining characteristics: they understand the problem you’re trying to solve are passionate about finding a solution, and if your model calls for it, are willing to pay. They do not have to be passionate about your solution, but recognize that nothing out there today adequately solves a problem that is very important to them. ## [Seven lessons I learned from the failure of my first startup, Dinnr](https://medium.com/indian-thoughts/seven-lessons-i-learned-from-the-failure-of-my-first-startup-dinnr-c166d1cfb8b8) Lesson #1: Are you solving an actual problem? we were not solving anyone’s problem. I should have found that out in my initial market research, especially in my 1–1 interviews. However, we committed the big mistake of presenting people with the idea and asking them if they liked it and would buy it. And when people said yes, WE thought they meant a) People want to make you, the founder, happy. b) People are too optimistic about their future behaviour. If they haven’t really thought about it, it means that it’s not high priority enough for them to bother. You learn that you’re not really solving a big enough problem for this particular customer but they still compliment you about it. People compliment you on the idea because they believe it will be so useful for people other than themselves. You must never, ever, pitch the product to the customer and ask for their feedback. One of the things the author recommends is to ask for commitment straight away. Simply telling my enthusiastic interview partners “ok, give me £20 and I will deliver you a prototype next Tuesday” would have yielded lots of interesting insights. I now think that few would have actually done it. In summary, a solution looking for a problem. I conducted market research superficially, let compliments go to my head, and assumed that the problems I was solving were big enough that people would pay money for the solution. Lesson #2. The fact you haven’t started a company before is not a reason to go with something easy The lesson is: All that matters is that I identify an opportunity. If I need market expertise, I will find someone or will learn it myself. If I need technical help, I will find someone or learn it myself. You can develop yourself towards stepping up to the opportunity. But you can’t conjure up an opportunity to suit your current skill level. Lesson #3: A concept’s success elsewhere is a small nudge, not half the journey. What I didn’t expect is that success in one market shouldn’t be anything but a little nudge, and not contribute more than maybe 1% to the entrepreneur’s decision-making whether to start something or not. The market research still needs to be done as thoroughly as if there hadn’t been market proof elsewhere. Lesson #4: Be your own worst critic, especially early on Especially in the early days, you need to be your own worst critic and shoot down your own idea from as many angles as possible and question everything. Lesson #5: Run a tight ship with development and design This is a quick one — We had offshore developers and designers who, despite coming with recommendations, didn’t execute well. Lesson #6: Professional design will not improve the business fundamentals The hypothesis of “make it visually more appealing and people will come back more often because you address their emotions” hadn’t worked out. The conclusion is — you can’t design your way out of a fundamental business flaw. Lesson #7: Expect results faster and attach consequences to goals not reached Once a goal hasn’t been reached, it would have helped us to sit down and to decide that we had to change course no matter what. In retrospect, it looks a bit crazy that we didn’t correct our course despite often not hitting the numbers. # Module 4: Designing the Solution ## [Pretotype:Make sure you are building the right it before you build it right](http://www.pretotyping.org/uploads/1/4/0/9/14099067/pretotype_it_2nd_pretotype_edition-2.pdf) Saved [here](../files/pretotype_it_2nd_pretotype_edition-2.pdf) Between abstract ideas and “proper prototypes” there are pretotypes. Pretotypes make it possible to collect valuable usage and market data to make a go/no-go decision on a new idea at a fraction of the cost of prototypes: hours or days instead of weeks or months, and pennies instead of dollars. Pretotyping helps you fail fast, recover fast and leaves you plenty of time, money, energy and enthusiasm to explore new tweaks or ideas until you hit on something that people seem to want – the rare and wonderful right it! ### C1: The Right It It is something that does not exist yet, but you have been thinking about it and would like to – or have to – create it and bring it to life. It is something important to you, and creating it will require a non-trivial combination of your time, effort and money, as well as a considerable amount of your energy, drive, enthusiasm and commitment. Ideally, it is something that you are deeply passionate about, but it’s OK if it is just something you have to do as part of your job. ### C2: Pretotyping In both examples, however, even the development of a “proper prototype” (a crude but functional version of the final product) would have required a lot of upfront time and a significant investment in research and development. Their solution to the “proper prototype” problem was to pretend that they had such a prototype. In the speech-to-text example, actual hardware and software was replaced with a bit of trickery, and in the Pilot example it was replaced by Hawkins’ imagination – fake it before you make it. Pretotyping [pree-tow-tie-ping], verb: Testing the initial appeal and actual usage of a potential new product by simulating its core experience with the smallest possible investment of time and money ### C3: It will fail The Law of Failure Most new its will fail – even if they are flawlessly executed Accepting this law will change your mindset from: “Let’s go for it! Let’s just build it, and go for broke!” to a more cautious “Let’s try it. Let’s pretotype it!” That’s right. For any given it, failure is not an option, but it’s the most likely outcome. We can’t get away from the Law of Failure. We can’t change the odds for new its. We invite failure, we seek it, we hunt it down and get it to show us its ugly face as soon as possible so we can determine if we are on the wrong track and make the necessary adjustments early on. The best thing you can do is feed the beast cheap little morsels of various its. The beast likes to eat wrong its but – given a chance – it would LOVE to eat you! You must be ready to toss morsels of your its to the beast and run away. If you don’t, if you get too attached to your it, and invest too much time developing it before dealing with the beast, you will probably end up having all your time and effort devoured by the beast. Thoughtland is a very safe place for ideas because, until they are actually converted into something more tangible such as a rough prototype of an app or the first draft of a book or script, they cannot fail. The only thing an abstract idea can “produce” is an opinion, something even more abstract and of even more dubious value. While safe for ideas, Thoughtland is a very dangerous place for creators, innovators, entrepreneurs and authors. The opinions that fester in Thoughtland and attach to our ideas can lead us to fail in two painful ways: False Negative opinions about our it can scare us into abandoning our idea so we do nothing with it. False Positive opinions about our it can blind us to The Law of Failure and cause us to prematurely overcommit and go for it ### C4: Pretotype it The Mechanical Turk – Replace complex and expensive computers or machines with human beings. The Pinocchio – Build a non-functional, “lifeless”, version of the product. The Minimum Viable Product (or Stripped Tease) – Create a functional version of it, but stripped down to its most basic functionality. The Provincial – Before launching world-wide, run a test on a very small sample. A Provincial pretotype provides the core features of the intended final product, but limits its scope (and scale) to support a small subset of the ultimate target market. The Fake Door – Create a fake “entry” for a product that doesn’t yet exist in any form. This could just be a web ad that people click into The Pretend-to-Own – Before investing in buying whatever you need for your it, rent or borrow it first. The Re-label – Put a different label on an existing product that looks like the product you want to create. ### C5: Test it Initial Level of Interest - ask on forums and see how many actually respond Ongoing Level of Interest - does interest fade to zero? Check the level of interest over time ### C6: Putting it all together ILI 1 = number of clicks on ad / number of ad impressions (i.e., how many people have seen the ad) ILI2 = number of emails / number page visits to the landing page Only when your OLI is clear, then you invest into making it scalable ### C7: Now go make it innovators beat ideas pretotypes beat productypes data beats opinions now beats later doing beats talking simple beats complex commitment beats committees ## [Usability Testing: How to Do It & Its Benefits for Business](https://uxstudioteam.com/ux-blog/usability-testing/) Our usability testing definition is the following – it helps to validate product ease-of-use and its functionality. Usability testing is one of the user experience research methods, usually a qualitative one, and it is the core of UX research. A user should interact with a digital product without frustration and easily accomplish set goals. There is no strictly defined usability testing process. You’ll have to fine-tune and customize it to your needs. However, the most critical first step is to learn the basics of usability testing, start doing UX testing and make it an essential part of your UX process. Typical usability testing examples: * Identify the product’s main pain points. * Check if users understand the navigation. * Observe how easily and quickly people accomplish tasks.Validate the value proposition of an app or website. * Do your potential customers understand it? * Test competitors’ solutions. (You can test competitors’ solutions with the target group to gain insights on what could be changed or improved in your product.) When to do it: * When forming a concept, you can test low-effort paper prototypes or competitors’ sites. * At the beginning of a project – test the current design solution that you want to improve. * UX design or redesign phase. * During the development phase. How many? According to Nielsen, testing five people in one cycle reveals 85% of all usability issues. After a round, prioritize the problems and work on them, iterate, and test again. Another popular framework, RITE (Rapid Iterative Testing and Evaluation), promotes faster processes and solutions. It favors running one usability-test and correcting the discovered problems immediately afterward. ### 4 steps of a usability test 1: Plan your study Clarify: The product to test: Are you onboarding a mobile app, a website filtering system, or a kiosk interface prototype? The platform: When testing a mobile app, determine if the OS matters and if it might bias the study. If so, let participants choose the OS. Research objectives: If users understand passwordless registration and login. If they can easily navigate the product detail page. Turn your high-level objectives into concrete usability testing questions. Concentrate on a few tasks, pages, areas, and assumptions to test at once. Target audience: Who are they? How many participants do you need? How are you going to reach them?What will you give as a reward? (money, gift card, discount, tickets, lifetime access to your product, etc.)How do you make sure the participants are your target audience? Remote or in-person: Base your decision on the type of product, project scope, objectives, and target audience. Choose the more feasible one (technically and financially). Write a usability study plan: * Goals * Participants * Setting (where, when, device type) * Roles (moderator, observer, note-taker) * Tasks Write a usability testing script: Inform users what the usability test purpose is and how their feedback can help create powerful digital products. Adjust the usability test script according to participants’ prior knowledge. Some explanation is required on what a prototype is if they have never heard of the concept. Come up with a realistic scenario. You want to hear users’ personal reactions to the product. Help them engage in the testing. Come up with the exact usability testing questions and tasks you want your participants to perform. They should find the scenarios and tasks as realistic as possible. 2: User test participants To make sure your potential user test participant fits the criteria, make a screener. You can have an online form or pose the screening questions directly over the phone. The work is almost done. However, you’ll still have to keep track of everyone, handle your inbox, and schedule test sessions. 3: Lead usability test Pilot test Make sure to test the usability test! Take it for a dry run or do a pilot. The pilot participant doesn’t have to come from the target audience. Run a session with a colleague or ask your friends for help. During the test Scenario: Make the scenario-specific and realistic so your participants could perform it elsewhere. Help thoroughly paint the picture for participants so they can easily imagine the scenario. Warm-up questions: Needs: Where does the problem arise? What are they looking for? Experience: How do they use similar products? Intentions: Why do they use those products?Knowledge: What do they know about the topic? Tasks: At UX studio, we always give participants tasks to focus their attention on some area or aspects of a user interface. Whether it is an overall impression of the landing page or the process of buying shoes on an e-commerce platform. There are three types of tasks: * Broadly interpreted: These instructions show how users start using the application and figure out what it does. “Discover the ways you could use this application to enhance your performance.” “Explore this landing page and see what this company offers.” * Tasks related to a particular goal: These tasks aim to test specific processes. “Buy a TV!” “Sign up!” * Tasks related to specific interface elements: “Where can you subscribe to a newsletter here?” “How can you put an ebook in the basket on this screen?” After the test Feeling like a test subject (in place of the product) can frustrate participants. It might happen even if you try your best to emphasize they are not the ones being tested. Participants might remain tense until the very end of a session. To help your participants relax, ask them how they felt and perceived their experience. A bit of post-test chit-chat indicates the “serious” part of the test has finished, and they can share their honest opinion. It helps open up some people, and they might give a lot of feedback during the post-test questions. Post-test question examples * Did I forget to ask you about anything? / Would you like to mention anything? * On a scale from 1 to 10, how easy was it to use? (You might break it down according to different tasks) * What three main things did you like the most about the app or this experience?What are the three things that confused you or you didn’t like? * Did it lack anything? 4: Analyze and report For more extensive projects with weekly usability tests, it might merit building up a research system to synthesize your endless number of observations and insights into a searchable, consistent system. For a leaner approach, try to include the essentials only, such as task, observation, location (page, step), issue severity. If possible, set up a meeting after a round of tests, so you can help stakeholders understand the results and answer emerging questions. Provide snippets of test recordings, include screenshots and quotes from the participants. It will shift the nature of the usability tests from very abstract and mysterious research activity to a tangible method contributing to informed product decisions. It will also help organize the vast amount of feedback, information, and insights from usability testing sessions. ## [The Psychology Principles Every UI/UX Designer Needs to Know](https://uxplanet.org/the-psychology-principles-every-ui-ux-designer-needs-to-know-24116fd65778) Von Restorff effect “When multiple similar objects are present, the one that differs from the rest is most likely to be remembered!” Serial position effect The Serial Position Effect is the propensity of a user to best remember the first and last items in a series. Cognitive load Cognitive load refers to the total amount of mental effort being used in a person’s working memory. To put it simply, it is the amount of thought you need to exercise in order to complete a specific task. 1. Intrinsic cognitive load - Intrinsic cognitive load is the difficulty associated with a specific instructional topic. 2. Extraneous cognitive load 3. Germane cognitive load - Germane cognitive load is the cognitive load devoted to processing information and construction of schemas. The schemas describe a pattern of thought that organises categories of information and any relationships among them. Hick’s Law Hick’s Law describes that the time it takes for a person to make a decision depends on the choices available to him or her. So if the number of choices increases, the time to make a decision increases logarithmically. Law of Proximity Law of proximity is part of the Gestalt Laws of Perceptual Organization, and it states that objects that are near, or proximate to each other, tend to be grouped together. To put it in simpler terms, our brain can easily associate objects close to each other, better than it does objects that are spaced far apart. This clustering occurs because humans have a natural tendency to organise and group things together. ## [Prototyping: Learn Eight Common Methods and Best Practices](https://www.interaction-design.org/literature/article/prototyping-learn-eight-common-methods-and-best-practices) 1. Sketching You can also sketch diagrams and mind maps in order to illustrate a system, process, or the structure of your ideas. You can sketch the various touch points that affect a user’s journey, and then identify how they relate to one another. Alternatively, you can visualise and analyse how your ideas can relate to one another and complement (or sometimes compete with) one another. Diagramming is a useful way to understand complex situations or use cases, where many factors and players affect one another. Journey maps, behaviour maps, system flow diagrams, and a range of other mapping methods are at your service to help you scope out complex situations. 2. Paper interfaces When you use paper interfaces, however, you can uncover many areas for improvement, such as usability issues, that can help you make improvements to your design in the early stages, thus avoiding production costs. According to Nielsen, usability studies show that early-stage changes are about 100 times cheaper than changes made in later stages of a product development process. 3. Storyboards Storyboarding, as a prototyping method, ensures that we know our users well enough (it would be hard to sketch a storyboard otherwise) and allows us to keep in mind the context of the solution we are designing. It is useful for developing an empathic understanding of users — and for generating high-level ideation and discussions. Storyboards, however, are not very useful for fine-tuning the details of products, because the drawings tend to be more macroscopic in nature. 4. Lego prototyping As a designer, you can take advantage of Lego’s ubiquity and versatility to create quick and simple prototypes of your ideas. The best part of using Lego to build your prototypes is that they become easy to dismantle and tweak; simply detach a part of your Lego prototype, swap it with an alternative design, and play with it to see if it works. 5. Role playing We can use role-playing with varying levels of detail, but the best experience happens when you simulate the physical environment of the user. You can create props, use objects around your workplace (such as chairs and desks), and use audio simulations by playing a soundtrack that mimics the user’s environment. If you are the facilitator of the role-playing exercise, assign each participant a role, and choreograph certain skits depending on the purpose of the role-playing exercise. For instance, if you are trying to feel the emotional experience of using your service solution, your team can act out the parts of a user and a service provider. 6. Physical models The purpose of a physical model is to bring an intangible idea, or two-dimensional sketch, into a physical, three-dimensional plane. This allows for much better testing with users, and it can spark discussions about the form factor of the solution. 7. Wizard-of-oz prototypes Wizard of Oz prototypes are prototypes with faked functions — for instance, interactivity that comes from a human rather than an algorithm or software code, with users believing the latter is the case — that you can use to test with your users. 8. User-driven prototypes A user-driven prototype is unlike any other prototyping method previously mentioned. Instead of building a prototype to test on users, you will instead get the user to create something, and from the process learn more about the user. When you ask the user to design a solution, rather than provide feedback on a prototype, you can learn about the assumptions and desires that the user possesses. ## [The GV research sprint: a 4-day process for answering important startup questions](https://library.gv.com/the-gv-research-sprint-a-4-day-process-for-answering-important-startup-questions-97279b532b25) There are five essential components of a research sprint. 1. A set of questions and assumptions. Without these, you’re not making the most of your effort. Before starting the sprint, everyone on the team should agree on the questions you plan to answer and the assumptions you plan to test. 2. Intentional and selective recruiting. You’ll need to carefully recruit people based on your goals: existing customers, prospective customers, representative customers, etc. In other words: Unless you’re building a product for Starbucks customers, you shouldn’t randomly conduct interviews with people at Starbucks. 3. A realistic prototype you can test. You can learn a lot by listening to people, but you can learn much more by seeing how they react to a realistic prototype. The more realistic, the better — you want people’s real reactions to what you’re building, not their abstract thoughts or smart-sounding feedback. (Check out some real prototypes we built in one day each.) 4. Five 1-on-1 interviews combining broad discovery questions with task-based evaluation of a prototype. 1-on-1 interviews (in person or remotely) are the best-bang-for-your-buck type of qualitative research. You’ll learn from facial expressions, gut reactions, and body language. You can ask follow-up questions and follow interesting tangents. Why five? It’s easy to spot patterns, and you can do five 60-minute interviews in one day. We’ll help you write an interview guide that keeps you on track during the interviews. (Watch this 7-minute video for a quick demo of what these interviews look like: How to Test Prototypes with Customers: The Five-Act Interview.) 5. Real-time summarization of findings. One thing that slows down many forms of research is the analysis — it can take days or weeks to extract findings from the data. In a research sprint, the entire team watches the interviews, takes notes, summarizes the findings, and decides on next steps before heading home for the day. ## [An MVP is not a Cheaper Product, It’s about Smart Learning](https://steveblank.com/2013/07/22/an-mvp-is-not-a-cheaper-product-its-about-smart-learning/) A minimum viable product is not always a smaller/cheaper version of your final product Think about cheap hacks to test the goal Great founders keep their eye on the prize ## [Define and Frame Your Design Challenge by Creating Your Point Of View and Ask “How Might We”](https://www.interaction-design.org/literature/article/define-and-frame-your-design-challenge-by-creating-your-point-of-view-and-ask-how-might-we) Your Point of View (POV) defines the RIGHT challenge to address in the following mode in the Design Thinking process, which is the Ideation mode. A good POV will allow you to ideate and solve your design challenge in a goal-oriented manner in which you keep a focus on your users, their needs and your insights about them. Step 1 * Define the type of person you are designing for – your user. For example, you could define the user by developing one or more personas, by using affinity diagrams, empathy maps and other methods, which help you to understand and crystallise your research results – observations, interviews, fieldwork, etc. * Select the most essential needs, which are the most important to fulfill. Again, extract and synthesise the needs you’ve found in your observations, research, fieldwork, and interviews. Remember that needs should be verbs. * Work to express the insights developed through the synthesis of your gathered information. The insight should typically not be a reason for the need, but rather a synthesised statement that you can leverage in your designing solution. Step 2: Group them into User, Need, Insight Step 3: [User . . . (descriptive)] needs [Need . . . (verb)] because [Insight . . . (compelling)] Step 4 – Make Sure That Your Point Of View is One That: * Provides a narrow focus. * Frames the problem as a problem statement. * Inspires your team. * Guides your innovation efforts. * Informs criteria for evaluating competing ideas. * Is sexy and captures people’s attention. * Is valid, insightful, actionable, unique, narrow, meaningful, and exciting. How Might Wes The How Might We question purposely maintains a level of ambiguity, and opens up the exploration space to a range of possibilities. It's a re-wording of the core need, which you have uncovered through a deeper interrogation of the problem in your research phase, the Empathise mode in Design Thinking – and synthesized in the Define mode in Design Thinking. "How" suggests that we do not yet have the answer. “How” helps us set aside prescriptive briefs. “How” helps us explore a variety of endeavors instead of merely executing on what we “think” the solution should be. "Might" emphasizes that our responses may only be possible solutions, not the only solution. “Might” also allows for the exploration of multiple possible solutions, not settling for the first that comes to mind. "We" immediately brings in the element of a collaborative effort. “We” suggests that the idea for the solution lies in our collective teamwork. 1. Begin with your Point of View (POV) or problem statement. Start by rephrasing and framing your Point Of View as several questions by adding “How might we” at the beginning. 2. Break that larger POV challenge up into smaller actionable and meaningful questions. Five to ten How Might We questions for one POV is a good starting point. 3. It is often helpful to brainstorm the HMW questions before the solutions brainstorm. 4. Look at your How Might We questions and ask yourself if they allow for a variety of solutions. If they don’t, broaden them. Your How Might We questions should generate a number of possible answers and will become a launchpad for your Ideation Sessions, such as Brainstorms. 5. If your How Might We questions are too broad, narrow them down. You should aim for a narrow enough frame to let you know where to start your Brainstorm, but at the same time, you should also aim for enough breadth to give you room to explore wild ideas. ## [How to Build a Minimum Loveable Product](https://medium.com/the-happy-startup-school/beyond-mvp-10-steps-to-make-your-product-minimum-loveable-51800164ae0c) MVP The version of a new product that brings back the maximum amount of validated learning about your customers with the least effort. MLP The version of a new product that brings back the maximum amount of love from your early tribe members with the least effort. 1. Give it a point Without a clear purpose that drives decisions, a product can seem bloated and pointless. Simon Sinek points out that you need to awaken an emotion with your early customers so that they feel something and that most buying decisions are based on emotion, rather than logic. 2. Do one thing well One way to achieve this focus is by developing your Blue Ocean Strategy. A simple but effective framework for developing a targeted value proposition. It allows you to consider ways in which you can stay ahead of the competition and create new value. 3. Timebox it You need to prioritise. Without prioritising what’s important to you the road ahead will be a rocky one. By setting constraints on time and budget this forces you to reduce the scope. 3 months is enough time to deliver on your vision but not long enough to lose sight of it It’s enough time to make something high quality but not long enough to get bogged down in perfectionism It’s enough time to develop a rhythm and habits but not long enough that you stop questioning them It’s enough time for a team to gel but not long enough for it to get stale It’s enough time to spend the budget efficiently but not enough time to spend too much or go too far astray It’s enough time to develop what you need to but not enough time to develop things that might start diluting the product 4. Solve only high value problems Only focus on building features that relieve your customers’ pain and allow them to get their jobs done simply and easily. 5. Add surprise & delight What can you do to create a positive response from your customers? Go above and beyond what’s expected of you and you’ll reap the rewards. 6. Put your money where your mouth is It’s been proven that there’s a direct correlation between a positive user experience and loyalty. Happy customers tend to spend more, more often and tell their friends. 7. Make ‘em hungry for more Trigger The trigger is the actuator of a behavior — the spark plug in the engine. Triggers come in two types: external and internal. Habit-forming technologies start by alerting users with external triggers like an email, a link on a web site, or the app icon on a phone. Action After the trigger comes the intended action. Here, companies leverage two pulleys of human behavior – motivation and ability. This phase of the Hook draws upon the art and science of usability design to ensure that the user acts the way the designer intends. Variable Reward Variable schedules of reward are one of the most powerful tools that companies use to hook users. Research shows that levels of dopamine surge when the brain is expecting a reward. Introducing variability multiplies the effect, creating a frenzied hunting state, activating the parts associated with wanting and desire. Although classic examples include slot machines and lotteries, variable rewards are prevalent in habit-forming technologies as well. Investment The last phase of the Hook is where the user is asked to do bit of work. The investment implies an action that improves the service for the next go-around. Inviting friends, stating preferences, building virtual assets, and learning to use new features are all commitments that improve the service for the user. These investments can be leveraged to make the trigger more engaging, the action easier, and the reward more exciting with every pass through the Hook. 8. Build your tribe One effective way to build your tribe is to nail your colours to the mast and create your own manifesto before you release a product. 9. Make it remarkable So don’t be a little bit different. Be very different. Don’t be so safe you’re easy to ignore. Give people a reason to talk. 10. Make it part of a strategy You need to clarify and communicate your vision so your team is clear where you’re going, what your strategy is and where the MVP fits into this. Bear in mind that your first release should the start of your journey towards product-market fit, not the end of the road. ## [The Difference Between Good and Great Designers](https://modus.medium.com/the-difference-between-good-and-great-designers-fd6d4d8bd813) A specialist is someone who excels at one thing and approaches their work in a formulaic way. By figuring out why a problem exists in the first place, a great designer doesn’t just mitigate its effects — she can eliminate the problem completely. Being a specialist, even one with a broad skill set, is not enough to arrive at that result. A systemic (or holistic, if you will) approach is needed. A great designer needs to exercise strong opinions, making them come to life through skillful execution. It’s worth noting that “opinionated” is not the same as “being loud with one’s opinions.” A great designer doesn’t feel contempt toward people who use her product, and never assumes they’re too stupid to understand it. It is her job to arrive at a solution that is unambiguous. It is her duty to hold strong conviction about what the world should look like, while exercising humility in the arduous process of making it better. The difference between a good designer and a great designer is not a difference of quality. It is a difference of kind.