Table of Contents
- About the Book
- Chapter 1: You, and the Business of ‘Digital’
- Chapter 2: From Idea to Design
- Chapter 3: From Design to Code
- Chapter 4: From Code to Deploy
- Chapter 5: From Release to Experimentation
- Chapter 6: From Inference to Your Next Product Priorities
- Chapter 7: The Economics of Code
- Chapter 8: Application Infrastructure
- Chapter 9: Data, Big Data, Data Science & Machine Learning
- Chapter 10: Security
- Chapter 11: Growth Hacking & RevOps
- Chapter 12: You, the Hypothesis-Driven Developer
Hello! This is a reference for the book ‘Hypothesis-Driven Development: A Guide to Smarter Product Management“.
About the Book
There’s a lot of waste in tech. Billions of dollars of it. Software gets written and digital products designed and shipped that no one wants. Some say it’s “just a part of doing the business of innovation” in hot new markets.
But waste is not inevitable anymore.
Hypothesis-Driven Development (HDD) is an emerging approach to digital product management for both business people and engineers. It emphasizes rigorous, continuous experimentation as a way to both minimize waste and focus teams’ creative capabilities in directions that drive growth and innovation.
Chapters
| # | CHAPTER | WHAT YOU’LL LEARN |
| 1 | You, What’s Changed, and Collaborating in Tech | How do you prepare yourself for a successful career in tech?
After this chapter, you will be able to:
|
| 2 | From Idea to Design | As the business lead on a tech team, what is your role and how do you do it well?
After this chapter, you will be able to:
|
| 3 | From Design to Code | What does it take to go from design to code? Do you need to learn to code? If so, what does that mean? When and why does it matter?
After this chapter, you will be able to:
|
| 4 | From Code to Deploy | How do you rapidly get new features in front of customers without stressing your team? What investments does this require and how do you evaluate them?
After this chapter, you will be able to:
|
| 5 | From Release to Experimentation | How do you make a habit out of experimentation? How do you make it useful enough for the team and easy enough to consistently do as you release?
After this chapter, you will be able to:
|
| 6 | From Inference to Your Next Product Priorities | How do you know if you got it right, or you need to rinse and repeat? How do you instrument observation and set thresholds to make the hard but necessary decisions about what to prioritize?
After this chapter, you will be able to:
|
| 7 | The Economics of Code | What drives the cost of releasing a successful feature? And how does that relate to the technology choices a team makes when building an application?
After this chapter, you will be able to:
|
| 8 | Application Infrastructure | Where do applications run? Given the pain points of deploying applications and keeping them running, what is the marketplace for approaches to do this? When, why, and how are those economical?
After this chapter, you will be able to:
|
| 9 | Data, Big Data, Data Science & Machine Learning | What can you do with a lot of data? How do you decide when, where, and how to invest? How do you integrate such a capability with your general product program to maximize its relevance?
After this chapter, you will be able to:
|
| 10 | Security | Where’s the insecurity in digital? It’s pretty much everywhere, but how do you identify, prioritize, and manage risk?
After this chapter, you will be able to:
Please Note: This chapter is terrifying and you should only read it if you want to know the truth. |
| 11 | Growth Hacking & RevOps | How has the move from physical products and print media to digital changed the way we test what will engage a customer?
After this chapter, you will be able to:
|
| 12 | You, the Hypothesis-Driven Developer | What are your next steps?
After this chapter, you will be able to:
|
The sections that follow detail the recommended practice for each chapter of the book. If you’re reading the book, I’ll just mention again that the idea is not to go through all off this practice each time you finish a chapter. Instead, what I’d recommend is finishing the book so you get the larger picture of how you might apply HDD to your work and then consider, week to week, month to month, where you might find the most relevant opportunities for practice, using this guide.
Chapter 1: You, and the Business of ‘Digital’
How do you prepare yourself for a successful career in tech?
After this chapter, you will be able to:
- Explain the key operating foundations of tech and how it might relate to a given career trajectory
- Analyze the economic significance and performance criteria of a technical team in terms of a product pipeline
- Apply a disciplined, focused, yet innovation-friendly view of strategy to a tech product or company
The following subsections describe the recommended practice from Chapter 1.
Describe a Business and its Product/Market fit with the Business Model Canvas
Tutorial on the Business Model Canvas
Printable Business Model Canvas
Digitally Editable Canvas Template on Google Docs
For more depth on the topic, check out this online course:
Online Course: Facilitating with the Business Model Canvas
(≈4 hours including quizzes and practice)
Charter and Focus a Team with OKRs
John Doerr’s website has a set of examples I’ve found quite sufficient for getting started with OKR’s: What Matters: OKR Examples.
If you want a lot more depth, he also has a book on the topic: Measure What Matters.
Practice Agile
Online Tutorial: Agile: Just the Basics
If you prefer something more business school, here is a tech note I wrote with a colleague: Agile Development
Finally, if you want something more directed and even broader because knowing about agile is one of your top priorities right now, here is my online course: Managing with Agile.
Strategy Meets Digital
For this, I highly recommend my colleague Mike Lenox’s book on digital transformation (coming soon) or his online course ‘Digital Transformation‘.
Teaching a Degree Program Course or Workshop with This Material
The links below reference full syllabi, including assignment templates, for a few HDD-related classes I teach:
Digital Product Management
Software Design
Software Development
Digital Capstone
Hypothesis-Driven Development for Analysts [COMING SOON]
Chapter 2: From Idea to Design
As the business lead on a tech team, what is your role and how do you do it well?
After this chapter, you will be able to:
- Explain the concept of product/market fit in economic terms
- Analyze the work of a business or product lead in terms of a sequence of testable hypotheses that minimize waste and maximize wins
- Do the work to make sure your team is focused on a job/problem/need/desire that actually exists for a certain identifiable buyer or user.
- Avoid false positives and minimize waste by applying Lean Startup to testing whether your proposition is competitive with the prevailing alternatives
- Make a habit of designing for and testing usability early and often so you minimize friction for the user
- Identify the analytics necessary to make crisp decisions for an iterative, emergent design
The following subsections describe the recommended practice from Chapter 2.
Build Your Personal Innovation Portfolio
This tutorial is a good place to start: Creating Your Personal Innovation Portfolio. It offers example entries (like this one) and templates in Google Slides you can use to jump start the process.
The page offers examples and starter templates for project types like customer discovery, application design, application development, and data science.
Focus and Test a Right Problem (Persona & JTBD) Hypothesis with Subject Interviews
This template is a good place to start: HDD Template/Personas, JTBD, and Discoveries. A good batch of steps is to: a) draft personas & JTBD, b) draft an interview guide and conduct interviews, c) revise your draft personas and JTBD.
‘Day in the Life’ is another related tool, particularly useful for bringing your discovery work to life for colleagues who weren’t out there with you. This tutorial offers notes, examples, and a template: Day in the Life Tutorial.
Focus And Test A Demand Hypothesis With Lean Startup
This tutorial is an excellent place to start: Tutorial on Proposition Testing with Lean Startup. It links to a template, which is a section in the same HDD Template I mentioned above (in the section on Right Problem Hypothesis).
Focus and Test a Usability Hypothesis with User Stories
This tutorial is an excellent place to start: Tutorial on Anchoring a Usability Hypothesis with User Stories. Here again, the HDD Template above also offers a place to organize and integrate this material with your work on ‘right problem’ and demand/proposition testing.
Define and Apply Visual Consistency
This tutorial offers a step by step view on how to do this: Tutorial on Creating Visual Consistency with a Style Guide. It also links to a set of example guides (ex: COWAN+) whose format you can use as a starting point.
Learn More about the Practice of Design and Design Thinking
For more on the core practice of product design, you may be interested in Donald Norman’s book The Design of Everyday Things, which is heavily cited in my HDD book.
For more on the practice of design thinking, applying the lens of product design to a wider set of business problems, I highly recommend The Designing for Growth Field Book.
Chapter 3: From Design to Code
What does it take to go from design to code? Do you need to learn to code? If so, what does that mean? When and why does it matter?
After this chapter, you will be able to:
- Unpack digital infrastructure in terms of the model-view-controller (MVC) framework
- Identify and practice the key steps to creating a View
- Analyze and decompose a user experience in terms of its Controllers or algorithms
- Structure real world entities in terms of an implementation-friendly Model
The following subsections describe the recommended practice from Chapter 3. This sub-sections lean pretty heavily on the MVC (model-view-controller) framework. For a review on that, check out this 5 minute video (MVC Tutorial).
Create a Style Guide to Delivery Consistent Visceral Reactions to Your Views
If you already did this in the recommended practice for Chapter 2, you’re probably in good shape. However, if you’re getting ready to go from design to code on something, this is a useful thing to do now- even if it’s just a text file with some notes on which colors and typefaces you’re going to use. The tutorial here will help you get started: Tutorial on Creating Visual Consistency with a Style Guide.
Create Views with HTML & CSS
The #1 most important thing for this practice and the practice in the sub-sections that follow has nothing to do with coding itself. The most important thing is to have an idea that you’ve thought through. This could be a whole application or even just a simple interaction you’ve noticed and would like to try improving. The reason this is so, so important is that without some kind of focal point for what you want to have happen, you’ll likely get lost in all the hooks and dials and technical minutiae of the various coding facilities. This is a bad thing. Even professional developers don’t go through and memorize everything a given programming language can do. They figure out what they want to have happen first, and then figure out how to make it happen with the coding facility in question.
Yes, there are some fundamentals for each programming language and there’s an experience curve across which going from design to code gets easier. The various options below (online courses, cases, and tutorials) all focus on introducing fundamentals and then quickly transitioning you to a specific problem/task for applied practice. You’ll need to use references (aka Google search) to figure out individual items, like ‘How do I make a rounded border with CSS?’. However, what you should not do is first try to memorize all the hundreds of things that HTML or CSS can do. All that said, here are a few ways to get started with creating Views.
If you like to dive in and just start fiddling, you may want to start with the various case challenges, which you can find here: Coding Cases (Design to View). The first three cases (From Prototype to HTML, Making HTML Manageable, and Debugging HTML & CSS) will give you a solid footing in going from design to code in this area. From there, you can use the same development environment to start working on your own project.
If you’d like something more structured and stepwise, I’ve created a set of online courses around those same cases and some of the related reading. The first one, Coding for Designers, Managers, and Entrepreneurs I, will take you through the cases above.
Finally, if you’re interested in teaching a class or even just maybe a peer support group (kind of like a book club for product people- but for coding!), then you may want to check out the syllabus I use for the degree program course in this area that I teach: Software Development. The first five sessions deal with creating Views with HTML & CSS.
Creating View Interactions with Javascript
Somewhere between the View and the Controller (words are faulty instruments), there’s the ‘front controller’, basically logic that creates interactive Views- views that afford more dynamic responses to user input for example.
If you want to dive in and start fiddling, check out this case: Making Stuff Happen with Javascript, and then invest some time on refining your skills with analytical debugging with this case: Debugging Javascript.
If you want something more step by step, check out the second course in the series above (Coding for Designers, Managers, and Entrepreneurs II).
Finally, if you’re looking to teach or facilitate a class/study group, sessions 7 & 8 from the Software Development syllabus in the section above focus on this aspect of going from design to code.
Creating Controllers with Javascript
Here you’ll transition more squarely to going from design to code with Controllers or ‘algorithms’.
If you want to dive in and start fiddling, this case deals with process automation and data transformation (super fun): Automating Your Gruntwork with Javascript.
Course II in the online course series (see above) offers a more step by step approach and session 9 from the syllabus above is where you’d do this case.
Mapping Data to Models and Operationalizing Them
Finally, putting the ‘M’ in MVC, we have a case on going from design to code with a data model. Rather straight away diving into all the mess and complexity of databases, the material here instead uses a modern NoSQL approach by way of Google’s Firebase ‘backend as a service’.
If you want to dive in and start fiddling, the case is: Creating & Managing Users with Google Firebase.
Course III in the course series above covers this case and the related concepts, as does session 10 in the syllabus (see above).
Chapter 4: From Code to Deploy
How do you rapidly get new features in front of customers without stressing your team? What investments does this require and how do you evaluate them?
After this chapter, you will be able to:
- Explain the major catalysts for change and success criteria for a modern, continuous product pipeline
- Unpack the steps from test to deploy for a given application
- Explain the role of version control in a product pipeline
- Analyze and evaluate investments in test capabilities, automated or otherwise
- Analyze and evaluate investments in deploy capabilities
The following subsections describe the recommended practice from Chapter 4.
Sketch Your Team’s Product Pipeline
The basic idea here is that you can’t improve a pipeline that you don’t (as a team) understand. The objective of this workshop/meeting is primarily just to sketch out an answer to ‘What is?’. Most likely, a set of ideas about where the roughest spots are and what changes you might want to test will arise from that naturally. Here are some notes on how you might do that with your team.
Who should be there?
Ideally, everyone on your team and, if the team’s not dedicated, then also all colleagues you regularly work with across the pipeline, including, say- test, sysadmin/ops, and analytics. Is that absolutely necessary? No, not to get started. It’s better to start texturing out the pipeline with a smaller group than to delay. But ultimately you’ll be best off with a fuller group for identifying, prioritizing, and testing changes.
What’s the agenda?
Have a whiteboard (physical or virtual) and bracket the pipeline as we’ve done here where it starts with ‘idea’ and finishes with ‘released software’. You may want to use one of the pipeline diagrams from the book/this site to introduce the general idea, but the terms your team or company uses may be different and that’s OK- the idea here is just to describe ‘What is?’.
From there, the idea is to fill in what happens between idea and released software. I highly recommend coming in with 1-2 specific examples, features that you’ve already released, and using those to anchor and the discussion and get all the way through the process. The current process may have forks, etc.- sometimes you do one thing, sometimes the other. I would get those both up there as messy as it may be- the idea here is to get to what is, and then, in small, success-based batches, test your way to what you all think should be.
Then what?
Getting a bunch of ideas on the board about which parts of the pipeline you want to improve is usually not too hard. You can simply right them on the board, take notes, or, have individuals write ideas on post-it’s (physical or virtual) and post them on the wall (again, physical or virtual). Converging on a prioritized set of choices is usually a little harder. Practices like dot voting can make that a little easier and more collaborative. However, the big thing to focus on is that you’ve got to start somewhere, each of these ideas has a specific, observable (ideally measurable) outcome that you’re testing it against, and you’ll by doing just then in your next or future team retrospective meeting after you’ve had a chance to test these ideas for improvement.
Concept and Prioritize Testable Changes to Your Product Pipeline
(see notes on the subsection above)
Draft an Agile Team Charter
The fundamental idea here is to have an entry point that answer the questions “What is this team working on and why?” as well as “How is the team currently collaborating?”. Does that mean everything that answers these questions needs to reside in the team charter itself? No. For example, you may have seen the HDD Template in some of the sections above, and it has some overlap with the team charter template. That’s fine. The core thing with the charter is to have an entry point. So, for example, if your team is happily keeping notes on its personas, JTBD, customer interviews, or other evidence someplace else just link to that from your charter. If you all keep meeting notes from your agile retrospectives someplace else, same idea- just link to it from your charter.
How do you know if it’s working? I’d look at two things. First, how often do various members of the team visit it? If it’s a Google Doc you have ready access to this, for example. Second, how well does it help onboarding new employees or team members?
All that said, this tutorial is a good place to start: Tutorial on Agile Team Charters. If you just want to get started, here is the template (just make yourself a copy): Team Charter Template.
Explain the Fundamentals of DevOps and Continuous Delivery
If you’re all in on the DORA metrics and generally like learning by book, Accelerate by Nicole Forsgren, Jez Humble, and Gene Kim is a great place to go next.
If you might prefer online courses, well, then I can’t help but recommend my own masterwork: Continuous Delivery & DevOps (Coursera).
Learn How to Manage Work with Version Control
On this one in particular, I would not invest a lot of time unless either a) you’ll be interacting with version control at least once in awhile or b) you just want to try it out and you’re OK forgetting most of the particulars if you don’t use it for, say, six months.
If you’re ready to give in, Github themselves (the leading VCS) offer a pretty good written tutorial: Hello World- Github.
If you want something more step by step and explanatory, Codecademy offers a good (free) online tutorial with hands-on practice: Codecademy Micro Course on Github.
Write Some Test to See How it Works
The Coursera course I mentioned above (Continuous Delivery & DevOps) steps through specific test development across unit, integration, and system tests.
If you want something more immediately hands-on, Codecademy offers tutorials here as well (though this one is paid only)- for example, this one is on unit testing Javascript: Unit Testing with JS.
Finally, it’s worth noting here that across all the different programming languages and the different layers of the test pyramid, there is a lot of stuff out there. If you’re curious about how testing happens in your current work, I would find out what toolchain your team uses and find resources to match- there will be plenty, you just have to know what you’re looking for. If you want a more general introduction that’s more in-depth than what you saw in Chapter 4, I would consider the online course: Continuous Delivery & DevOps (Coursera).
Understand the Managerial Side of How a Team gets to Healthier Pipelines
Full disclosure: this is currently a placeholder for something I’m working with some collaborators. I think it’s going to be useful if a general management perspective is what you’re after, but it’s not quite ready. That said, I think the items above are an excellent way to start on this.
Chapter 5: From Release to Experimentation
How do you make a habit out of experimentation? How do you make it useful enough for the team and easy enough to consistently do as you release?
After this chapter, you will be able to:
- Explain the fundamentals of experimentation in digital
- Pair important questions with rigorous but practical experiment designs
- Make a habit of pairing focused, relevant analytical questions with your agile user stories for purposeful analytics
The following subsections describe the recommended practice from Chapter 5.
Practice and Apply Innovation Analytics to Your work
As I mentioned in the book, my #1 recommendation here is to go deep on using experiments in your current work- whatever analytics suite you have, etc., it doesn’t really matter that much. Relevance is the big thing. I’d start by figuring out what questions you want to answer, how you might answer them (tools aside), and then figuring it yourself or working with colleagues, go get yourself some answers!
That said, if you want more depth on general practice, I recommend my own super great online course: Agile Analytics. I’m a biased? Yes. But, I did build the course specifically around the various focal points you’ve seen in the book so, for my money, it’s a good place to start.
That said, there are a lot of really good items out there. Stephen Thomke’s book Experimentation Works is an excellent intro to how companies are changing the way they operate with experiments. Trustworthy Online Controlled Experiments by Kohavi, et all is a more clinical take and widely read.
Design & Conduct an Experiment
#1 tip for getting started with experiments? Find something that interest you and an idea to make it better. Then test it. This section of the HDD template: Experiment Design is a good place to start.
The only other thing worth mentioning is that I would make sure you have a point of view on what general type of hypothesis you want to test. If it’s a motivation/demand hypothesis, look for relevant MVP patterns and make sure you’re not confusing it with a hypothesis about usability. Likewise, if it’s a hypothesis about usability, make sure you’re testing the subject’s ability to achieve a goal assuming motivation. Finally, if it’s a simple test in the wild (released software) of user action vs. inaction, that’s also fine- just make sure that’s clear in your hypothesis formulation.
Understand Frequentist vs. Bayesian Statistical Reasoning
Beyond what we’ve covered in the chapter, Google has done some excellent work in support of their Optimize tool. For more depth, this post is a good place to start: General Methodology. For frequentist statistics, just about any leading stat’s primer (which are the only ones you’ll find) is fine. For more on Bayesian inference, this is good as a follow-on from the Google piece: Bayesian Inference.
Chapter 6: From Inference to Your Next Product Priorities
How do you know if you got it right, or you need to rinse and repeat? How do you instrument observation and set thresholds to make the hard but necessary decisions about what to prioritize?
After this chapter, you will be able to:
- Start from a set of objectives and key results to charter a teams ‘true north’ success criteria
- Work backward from tangible goals in your descriptive analytics
- Think of your experiment designs as part of a longer game of adaptively getting to product/market fit
The following subsections describe the recommended practice from Chapter 6.
Sketch a CX Map
Here again, the main thing is just to pick something familiar with (a specific value proposition relative to a specific job-to-be-done) and start sketching. This tutorial offers a quick reference: CX Mapping, and you can start sketch on this section (CX Map) of the HDD template.
Take Your Metrics and Make them Better
My general preference is to start with the CX Map, but what if you already have a measurement infrastructure you generally like? The CX Map certainly is not the only way to go. This subsection of that tutorial offers a more general point of view on how to assess and (where applicable) improve your metrics from an HDD perspective: Making Better Metrics.
Chapter 7: The Economics of Code
What drives the cost of releasing a successful feature? And how does that relate to the technology choices a team makes when building an application?
After this chapter, you will be able to:
- Explain the major functional and economic dimensions between programming languages, libraries, and frameworks
- Identify and analyze the functional and economic footprint of application frameworks and development
- Analyze the economics of monoliths vs. microservices relative to an application’s key economic drivers
The following subsections describe the recommended practice from Chapter 7.
Learn about Your Product’s Stack or Stacks
Find the right person and start with a simple question like “What’s our tech stack?” or “What’s our tech stack for [specific application]?” More questions may not be necessary, but you can always follow that up with “How is that stack for you? How did you decide on it?” Be sure to express plain curiosity and you’ll almost certainly learn all you want and more!
Chapter 8: Application Infrastructure
Where do applications run? Given the pain points of deploying applications and keeping them running, what is the marketplace for approaches to do this? When, why, and how are those economical?
After this chapter, you will be able to:
- Explain the fundamentals of the stack where your application runs and its key outside interfaces
- Unpack the key cost drivers for operating your application and evaluate alternative solutions like data centers vs. cloud vs. platforms-as-a-service
- Explain the relationship between data exchanged through API’s or data-interchange formats vs. databases
The following subsections describe the recommended practice from Chapter 8.
Learn more about Technology, Economics, and Design Interact in Application Infrastructure
If you like to learn through case studies, as we do at UVA Darden, this is a case study on retrieving a large scale IT project: Saving Griffin. That page also has a teaching note for the case and a tech note on agile- the tech note is a subset of the material in this book (not surprisingly), but if you’re doing an introduction for others you might find it useful.
Get Hands-On Practice Coding with API’s
This case will give you hands-on experience interacting with the API for Google Firebase, a very substantial backend-as-a-service platform: Creating & Managing Users with Google Firebase. It requires some familiarity with Javascript- but you can get that over the course of a few cases which I mentioned up in the materials for Chapter 3.
Deploy a Data Science Model to the Web
While it requires some familiarity with Javascript (for the client application), Python, and building predictive models with Python, it is amazingly easy to set up your own functioning application with multiple services (microservices, if you will). This ‘cookbook’ is a working item in Google Docs and will help you get started: Notes on Deploying Your Model with Flask. Finally, it’s worth noting that Flask itself is quite popular and well liked and you’ll find lots of other great resources with a few Google searches.
Chapter 9: Data, Big Data, Data Science & Machine Learning
What can you do with a lot of data? How do you decide when, where, and how to invest? How do you integrate such a capability with your general product program to maximize its relevance?
After this chapter, you will be able to:
- Analyze how and where to store your data to maximize your economics
- Frame your customer discovery in terms of ground truth and link it to dependent variables for actionability
- Identify and manage data science charters across descriptive, diagnostic, predictive, and prescriptive analytics
- Understand the data science process from data collection, preparation, exploration, modeling, and communication
- Identify key data science skill sets, including methods and statistical literacy, mechanics & algorithms, data intuition, and communication
The following subsections describe the recommended practice from Chapter 9.
Charter a Big Data Program with the Data Innovation Canvas
Data may be the new oil in a certain sense, but not all data is valuable. The Data Innovation Canvas is a thorough but lightweight tool for thinking through which data might end up valuable for you, both in terms of data you have and in terms of data you can create. This template on Google Slides (which you can download for PowerPoint) is a good way to get started: Data Innovation Canvas.
Get Hands-On Practice with Data
If SQL literacy is a big thing for you on the job, I recommend this relatively short (and free) tutorial from Codecademy: Learn SQL. The main thing is not to spend too much time on details ahead of meaningful, active practice either on the job or on a specific side project with some relevance to you.
If you want a more expansive introduction to data science, I like Jose Portilla’s course on Udemy: Python for Data Science and Machine Learning Bootcamp. There are plenty of resources, though I would avoid those with the language R and find ones that use Python, which is more generally applicable and ascendant. Here too, I’d look to go through the course relatively quickly and not worry about everything with an eye to getting started with active practice on a specific project.
Chapter 10: Security
Where’s the insecurity in digital? It’s pretty much everywhere, but how do you identify, prioritize, and manage risk?
After this chapter, you will be able to:
- Frame vulnerabilities across human and machine attack surfaces
- Understand several of the most prevalent attack vectors and publicly available data sources to identify them
- Identify how to link security with the rest of your product pipeline
Please Note: This chapter is terrifying and you should only read it if you want to know the truth.
The following subsections describe the recommended practice from Chapter 10.
Take Your Security Team Out for a Drink
Just do it. They need it. You’ll learn everything you wanted to know and more and you’ll never look at your computer the same way.
Chapter 11: Growth Hacking & RevOps
How has the move from physical products and print media to digital changed the way we test what will engage a customer?
After this chapter, you will be able to:
- Charter the activities of a digital marketing/promotion/growth hacking team based on your understanding of product/market fit
- Understand the relationship between and strengths of organic and paid channels online
- Participate in the design, execution, and evaluation of growth experiments
The following subsections describe the recommended practice from Chapter 11.
Sketch a CX Through the Hooked Framework
In my experience, the best thing is just to put pen to paper for a product you know. And don’t assume that the Hook doesn’t apply to enterprise/B2B products. Here’s a tutorial with some examples: Hook Framework.
Frame Your Point of View on Growth using the Growth Hacking Canvas
A lot of marketing is done with the age-old justification that “we’ve always done it this way” with the supporting evidence that things aren’t that bad (yet). This isn’t necessarily the best way to reduce waste and drive new, organic growth, though. Here’s a tutorial that steps through the Canvas: Tutorial on Scaling P/M Fit with the Growth Hacking Canvas. Or, if you just want to get started, here’s a template on Google Slides: Template- Growth Hacking Canvas.
Think through and Describe Your Brand Personality with a Moodboard
This is a great way to both think through your brand personality and connect it with a relevant visual execution: Brand Lattice (Moodboard Tool).
Facilitate Consistency with a Style Guide
OK, OK, this is my third mention, but if you don’t have one, this is definitely something I’d create (see above).
Chapter 12: You, the Hypothesis-Driven Developer
What are your next steps?
After this chapter, you will be able to:
- Prioritize and charter your own professional development based on your particular focus and current activities
- Facilitate HDD-friendly team charters to help your team improve its practice of agile through a focus on testable outcomes
- Facilitate clear, testable points of view on business model design to help align the work of teams
- For larger companies, charter, focus, and steward and innovation program with testable charters and governance
The following subsections describe the recommended practice from Chapter 12.
Summary Reference for the Book
(this page is the summary reference)
Create a Personal Innovation Portfolio (Recap)
This is a great way to both focus and showcase your practice of HDD: see above on Innovation Portfolio.
Sketch a Business Model Design (Recap)
If you want to make the product or line of business you’re working on easier to align with, this is a great place to start. See above on the Business Model Canvas.
Draft an Agile Team Charter (Recap)
If you want to facilitate aligned, autonomous, hypothesis-driven executions within a team, this is a great place to start. See above on Agile Team Charters.
Charter a Company Innovation Strategy with the Corporate Innovation Canvas
If you’re at a larger firm with multiple lines of business and outside investments, the Corporate Innovation Canvas is a quick and easy way to think about how all that is cohering (or not!), where you’d like to focus, and how you’ll evaluate success: Tutorial on Innovation Strategy with the Corporate Innovation Canvas.
