The value proposition canvas.

Where all great projects begin

What happens before writing the first line of code

Hi! We are Nicolas Backal and Katie Le, product designer and product manager at Okta. We have been working together for years, and we want to share the lessons we’ve learned through the lens of a cookbook with detailed recipes for creating a great design-product partnership.

Building a new product or feature from scratch can be quite an ambiguous task. You read online that PMs should start with a product spec, design should create some prototypes to validate, and that teams should have a brainstorming session to get the best ideas flowing. But what actually gets done before that first line of code is written? We think this part of product development process is harder than the execution. Not to say that our approach is the best way to do things, but it’s worked for us and we wanted to share what we did to get 2 successful projects into engineering hands.

Get alignment before starting your product spec

Before you even start a product spec, there are 3 things that are worth trying to align early team members:

1. Identify your dream team of eng/design/product at a minimum. We found that if you have too many people (> 6 people), the trust isn’t there and you don’t end up having quality conversations.
2. Establish a shared language: There’s no easier way to talk around in circles than to have meetings without a clear understanding of what you’re trying to solve for the user and what key terms mean. An example of how we knew we were failing at this was when team members who had been at the company a long time kept saying “how are we going to bootstrap our supply and demand?” — what does bootstrap mean? who makes up our supply? who makes up our demand? New folks didn’t know what we were talking about and didn’t ask until we wasted a lot of time. You can cover your bases by creating a doc outlining key terms that your team uses and what they mean. It comes in handy when linking to your spec later.
3. Brainstorm using a Value Proposition Canvas: To make that shared language even stronger, we did a value proposition brainstorm by filling out a Value Proposition Canvas together. While some parts of the exercise felt repetitive, we did get a lot out of explaining the value we were trying to create for users using Jobs to be Done and then prioritizing which jobs were the most important for us to solve. Without this exercise, we found that someone threw out a solution like “Company A has amazing onboarding. Let’s add Shiny Feature to make our onboarding better!” and then we would go down rat holes on how to build Shiny Feature when onboarding was low on the value prop list.

Work backwards using vision prototypes to get to your MVP

Before engineers ever write a single line of code, there needs to be a peer-reviewed product spec and prototype validated with customers. Here’s how we get to that:

1. PMs write the first half of the product spec: At this point, PMs need to go spend a week articulating the “first half” of the spec: problem, success metrics, user profiles, assumptions, customer value, compete, and user scenarios. Stop here and review with the team to prevent from going into solution space before you’ve aligned on the important aspects. The second part of the spec goes over the solution, phasing, launch, and user stories/requirements. In the past, we’ve tried starting this second part before having any prototypes, but later found that requirements ended up changing quite a bit once the design started. You might be asking “how does design start creating a solution without requirements from product?”. We align on the outcome and the experience we want through our user scenarios first. You know you’re doing it wrong if you’re spending more than 1 week alone on a spec — get feedback early.
2. Designers explore solutions and create vision prototypes with the team’s help: With the collateral from the brainstorm and the spec, this is where designers can shine and show strategic thinking by creating an ideal world prototype to get everyone super excited. We wrote a post on how to approach vision prototypes here. There’s no timeline for this phase as each designer has their own workflow, but we took 2 weeks to create high-fidelity vision prototypes with progress check-points twice a week. The competitive analysis that was done in the previous step, including screenshots of great products/flows in your solution space, is extremely helpful for design inspiration. Again, you know you’re doing this phase wrong if you’re spending more than 2 weeks alone without sharing designs and incorporating feedback.
3. Validate and create a decision journal: With these prototypes in hand, we started parallel work-streams for user research and experimental surveys. This is where tons of questions about the details emerge. We started a Decision Journal tracking all the major open questions that needed to be answered, and then moved each decision into a closed state when we made the call. Each question can take a meeting or more to resolve, and ours grew to over 20 pages with links to even more docs. This was great because it kept a record of every major decision we made with pros and cons so we could reference it later if needed. In addition to traditional user research, we used Pendo to run surveys on segments of users in our existing product to gauge interest in our solution, asking questions like “if we built this product, what would you most want to see?”. This phase can take weeks if not months depending on the complexity of the project, and it’s worth spending a lot of time here making sure what you’re building is right. If you’re rushing through this phase, not validating with real users, letting details fall through the cracks, and not facilitating pros/cons for each major open decision, we guarantee you’ll run into issues later when implementing.
4. Work backwards from the vision prototype to split up work into meaningful milestones: We would say that this was one of the hardest exercises — breaking up the vision prototypes into smaller, realistic chunks, which often times required creating entirely new designs based on the existing product but moving us closer to the vision. For example, our vision prototype had a brand new navigation that was much more intuitive, but we knew we wouldn’t get to that in the first phase. We had to go back to our existing navigation and build the key features into that instead, but it was extremely helpful knowing the end state and how this first phase would evolve into our end state. If everyone doesn’t know where the end state is or what it could look like, building incrementally could lead you down the wrong path and your engineers might have a harder time making small decisions along the way.

Recipe

1. Identify your dream team of eng/design/product at a minimum
2. Align around a shared language
3. Brainstorm using a Value Proposition Canvas
4. PMs write the first half of the product spec
5. Designers explore solutions and create vision prototypes with the team’s help
6. Validate and create a decision journal
7. Work backwards from the vision prototype to split up work into meaningful milestones

Ingredients

1. Long-form writing tool. We used google docs for the product spec and decision journal.
2. Brainstorming: We used Miro and FigJam to facilitate the value prop brainstorm. We also bought the book, Value Proposition Design so we knew how to conduct the brainstorm. We also used Miro to create a giant matrix of competitors, what they offered, and screenshots of great flows.
3. User Scenarios: Instead of writing requirements to guide design, we use user scenarios. This explains the ideal experience from the viewpoint of a user instead of prescribing how the solution should work.
4. Customer Value: Depending on the size of the project, we either explain the customer benefit in a few bullets, or we go with a full-blown press release, following Amazon’s philosophy.
5. Success metrics: We define lagging and leading indicators for each product, and this is a good read for picking which success metric is right for your product
6. Design prototypes: We used Figma to create high-fidelity prototypes. We also used Loom to create videos with a script walking through the prototype so it can be linked in the spec and shared with anyone new on the team.
7. User research tools: We used UserTesting to do unmoderated studies, and then did moderated studies using Respondent to recruit users with incentives. Without incentives, we typically reach out to customers or users with who we have great relationships to be early adopters.
8. Experimental survey tools. We used Pendo, but we’ve heard of UserLeap or you can build it in-house.