How to build product
This is a multi-step guide to how I approach building a product. Does this always work in real life? Of course not, but you need a mental model in order to get started. Here’s mine.
All typos and grammatical errors are my own because I wrote this guide standing up in my kitchen since 6:56 am EST on Feb 8th, 2018 and it is now 10:02 am EST. I’ll get to fixing it later, but wanted to get this out into the world.
To get the conversation going, let’s start with a seemingly simple question. Yes, it will get complicated because this is a multi-step guide to the art and science of building a product.
How do I build X?
- Start with a lean canvas to begin the ideation process. Formulate an initial hypothesis / thesis statement.
Lean Canvas
Problem
What problem(s) are we solving for?
How are these problems being solved for today?
Customer Segments
Who are our target customers / users?
Define the characteristics of your customers / users?
Unique Value Proposition
What is your message that will turn an unaware customer into an interested prospect?
What is the high level concept for the product/feature/solution? (e.g. This is the LinkedIn for PM”s)
Solution
What are possible solutions for each problem?
Channels
How do you intend to acquire customers?
Revenue
How do you intend to generate revenue?
Costs
What are you costs (fixed and variable) today?
Key Metrics
How do you qualify success?
How do you quantify success?
Unfair Advantage
What is your secret sauce that cannot be copied or bought elsewhere?
Is your solution a vitamin or a pain-killer? Is your solution something that exists in a blue ocean (versus red ocean)?
2. Begin user validation process to assess if the initial hypothesis reveals there is in fact a need for your product/feature/solution. E+A = C. Our hypothesis is an assumption, so we need to collect evidence to validate and reach a conclusion.
Define the customers/users you want to reach out to
Focus on the personas for your study and get their contact info (i.e. email address)
Define the location preferences of your audience? NYC, Midwest, Silicon Valley, etc?
Target industry? If seeking data on a financial product, you want people in finance
Create a Typeform, Google Form or use a service like Respondent to distribute
-Create a pitch
-Define how much time they should spend on study
-Incentives (money, t-shirt, etc)
-Demographics? Male, female, age, income range, etc?
-NDA needed?
-Write screener questions
Google Ventures has a good screener template to help define criteria and questions (https://www.dropbox.com/s/5kmofdms00sbh84/Google-Ventures-Research-Sprint-Screener-Worksheet.pdf)
Questions should be targeted to how people are solving the problem today, what they use to solve the problem, alternatives they use to solve the problem, use case definition, what is missing from their solution to the problem they would like to see, what is missing from their alternative solution that they would like to see, etc. Always keep in mind if this is for a new product to be built or a feature.
Be to sure to also define the customers/users you DO NOT want to reach out to*
3. Create a lightweight product spec that outlines what the product or feature will solve for. This lightweight document should include the prioritized features that will comprise the MVP.
The product spec will introduce the vision of the product or feature and convey the problem it is solving for, the goals the product/feature intends to achieve, the success metrics (definition of success), the target audience and a preview of the user stories that will comprise the MVP. The full list of user stories should be linked from the document to the issue tracking tool of choice (Pivotal, Jira, Trello, etc).
To help prioritize features for the MVP, we can use the following formula:
Significance = Magnitude x Number of people impacted. Magnitude can be an integer between 1 and 3 where 1 is a problem that causes mild annoyance, 2 is above annoyance, but not quite a showstopper and 3 is a showstopper that causes frustration.
4. Now that we have our initial documentation and overall product/problem definition in place, we would proceed to creating lightweight visuals (wireframes) to illustrate the basic look and feel of the product/feature.
The solution can be initially sketched out in wireframe format using a Moleskine notebook with digital pen to easily share with your team. A more detailed, annotated and clickable wireframe can be created in Balsamiq or Marvel.
If you have resources available and time, then your developer can create a mock version of the solution in parallel with actual working software. This is a solution that should be considered when feasible because there is nothing like reviewing early ideas on actual software to reveal additional evidence, assumptions and conclusions (E+A = C).
5. Usability Testing should follow once we have an initial prototype in place (paper, digital wireframe or software). The goal of the usability testing phase is to have users complete a set of tasks and understand their response to the solution, ask questions for improvements or reveal additional needs.
Create a script
Give an introduction and set the foundation for the goal of the usability test. We are testing the product, not you. Be honest, open and ask questions. Ask user under test to please think aloud as they navigate through the prototype.
Get context from your user’s behaviours and decision making process by asking open ended questions. How is the workflow solving your problem? What would you do to improve it? What would you remove? Which aspects of the prototype are clear? Which aspects are not clear?
By leveraging user stories created before (as a <type of user>, I want <some goal> so that <some reason>), provide your user under test a set of tasks for them to complete. Did they complete the tasks, where did they get stuck, where did they intend to navigation, but change direction, etc. Intent is important to understand and uncover.
Ask de-brief questions at the end of usability test. What did you like? What did you dislike? Was there any functionality that you wanted in this prototype? What parts of this prototype were very important for you?
6. Reflecting on the data captured from the usability tests, you will want to review all prior documentation, user stories, wireframes and prototypes in order to update these materials, create new entries for each, create new versions to compare the diff, etc.
Remember, the solution is going from current state (problem) to future state (solution). Easing friction to the latter is important.
7. Product Backlog
For a quick and dirty backlog for the MVP, you can leverage Google Sheets with the following columns: Date Added, Feature / Bug, Description, Impact, Urgency, Engineering Cost, Other Prioritization Criteria, Total Sum of Combined Priority, Status.
Other tools to use can be Jira, Pivotal Tracker, Trello, Asana, etc.
Remember, think in terms of Significance = Magnitude x Number of People Impacted.
Fill in the backlog with tasks, features, technical work and bugs based on data collected at this point in time.
Additional ways to find ideas to fill your backlog:
Feedback from users
Feedback from Social Media (Create word clouds)
Feedback from internal and external community forums
Feedback from customers (those paying for your solution or an adjacent solution
Feedback from internal teams and employees
Feedback from metrics (quantitative sources based on how people use a solution today)
8. Roadmap
Your roadmap will NOT be an exact timeline of development.
To structure your roadmap, you will want the following elements:
Product Vision — Forward looking statement, several years into future, that aligns team around what is being built / created and serves as a guide on what to prioritize, build, ship and learn from.
Objectives (2–3) — This should be goals, not tasks, that move your team toward vision. Examples can be reducing churn, more subscribers, new markets, new product lines, etc. Be sure to reflect on previous data collected in prior steps to inform the definition of objectives. Objectives/goals is the strategy component for your vision.
Bets — Under each objective that has been defined, you will want to list our your bets (tasks) that roll up and accomplish each objective in your roadmap. Don’t worry about segmenting roadmap into quarterly releases at this time. Bets are the tasks that constitute your roadmap to execute on your strategy that drives you closer to your vision.
There are different types of bets to consider when adding to your roadmap and it should include some, at least one, from each type: Sure Bets, Bets, Risky Bets.
For each objective, you can include 3 sure bets, 2 bets and 1 risky bet to ensure you are providing the most value for the MVP, while giving flexibility to introduce a high risk/high reward task. This needs to be vetted with your team and executive stakeholders so everyone is on the same page. You can represent bets with different colors (Green for Sure Bets, Yellow for Bets, Red for Risky Bets). This is similar to a traffic light so it can be easily understood by your audience for quick digestion.
Timeline — you can break down this roadmap into a quarterly schedule (Q1, Q2, Q3, Q4). Work with your team to understand their past work on quarterly projects of a similar nature to amend tasks in your roadmap. Deliver the most value to your customer early (Q1, Q2) and do not wait for Q3, Q4 to perform the challenging aspects of your roadmap. No one likes complications before the new year.
9. Execution Phase
Sit down with your team to align on the work to be done for your objective (Qx) to be completed within a 3 month time span. Everything should have priority, tasks and user stories should be defined and fleshed out. Technical pre-work and post work should be included also.
Work with your technical team lead on the work to be done first. Have an honest conversation with this person to understand the feasibility of your plan. This establishes trust and empathy as the cornerstone of a good working relationship. Then involve other business, client and executive stakeholders to meet with yourself and technical team lead to re-iterate and share the initial approach. Once everyone is in agreement and signed off, proceed to have this conversation with the people doing the work.
Executives & Leadership Team:
CEO (at your own company or client company)
CTO (at your own company or client company)
VP of Product (at your own company or client company)
Internal & External Partners:
Google (if using beta sdks for ads)
Salesforce (if using a private API)
Finance, Legal, Marketing, Sales
Execution Team:
PM
UX/UI Designer
Technical Team Lead
Developers
Test Engineers
Users & Customers:
Just because you’ve done all this work and you are in the execution phase does not mean you get to sit back and watch it all unfold. You need to be actively involved in gathering additional feedback from your users and customers (pull info) that will provide additional information into the problem to be solved for. Re-run user interviews and re-run usability tests with updated questions and updated prototypes to bridge the gap between E+A = C.
Remember, we have a hypothesis, a thesis, an idea for solving a problem. Constant iterative feedback and updating all prior steps and previously mentioned stakeholders is critical because this new information can have a material impact on what is being built and/or new information can be revealed from these folks (pushed info) that have a material impact. Material impact can be delays to timeline, increase in risk, increase in cost, technical blockers, etc.
Some Development Methodologies:
Waterfall:
Don’t do this in a modern technology company.
Very painful and high risk.
6 month to yearly release cycles
Lots of bugs
Lots of upfront and near perfect documentation required
SCRUM:
Sprint Planning
2-week sprints
Stand ups (what did you do yesterday, what will you do today, any blockers?)
Retrospectives
KANBAN:
Uses swimlanes (To-Do, In progress, Done)
Each team member takes items from column and moves along the swimlines
No timeboxed approach
Continuously working on items
Constraints — only a certain number of items in each swimlane
Works well with a mature team or a team that has developed a strong relationship
Hard to predict which items get done
These are the popular development methodologies, but not an exhaustive list of each approach in the wild. The idea here is to pick one based on how your team operates.
Make sure user stories and technical tickets are in your list of work to get done for the objective you are working towards.
Make sure you have creative assets in place for engineers to work from.
Figure out what work can be done by engineering to get started, get creative assets delivered while work is in progress.
Remember, iteration is key. Build, measure, learn, repeat!
10. Launch, Ship, Go-to-market, Deploy, Push to production
What superpower are we transferring to our customers to solve the problem?
This question should be constantly asked and challenged throughout the product development process in order to craft a compelling narrative. You want to ensure that you give something, a pain-killer, to get something (money, virality, accolades, etc).
Craft something that evokes an emotional response and kills the pain.
Why is this important? Because you will most likely need to work with your Marketing team to inform the market that your product will be released. Just because you build it does not mean people will show up to buy it.
Involved your marketing team as your backlog is winding down and being pushed into a stable branch. Give them time to test your product (beta release, gold master, etc) so they can feel, touch and experience it first hand.
Pushing to production is easy. You literally hit a button and your code is compiled and deployed to the destination of your choice. An oversimplification? Yes, but you get the idea!
Here are some strategies for launching, shipping, going to market, deploying, pushing to production your awesome new product:
Employee Only Rollout
-low risk while collecting data and feedback from employee, helpful for detecting bugs, ux problems; though employees are likely to be biased
Invite Only Rollout
Controlled size of users and the types of users
Need to set one metric for when full rollout is ready
Limited User Rollout
Restrict rollout to user type (free/paid), geography, demographics, platform/OS
Beta
Set user expectations while collecting user feedback
A/B Test
Ensure new feature/redesign does not hurt key metrics, compare with old
Gradual rollout
Rolling out to 5%, 20%, 80%, 99% of users gradually over time
Full rollout
Product or feature requires consistent experience for all users in order to bring customer value
Other things to remember
Always set goals and track metrics
Some rollout is aided by communication
Create a launch checklist (product, tech, legal, customer service, PR readiness, etc)
Make sure you have mechanisms in place to track the health of your product in the market, you understand the market’s response and learn what your internal and client team have to say about it also.
11. Summary
Phew! This is my templated approach to building product and hopefully you have enjoyed reading this.
What’s the point?
Think it!
Build it!
Ship it!
Measure it!
Learn from it!
Make it better next time!
Add new stuff next time!
Repeat it!
