Building Software Products

This is my take on how to build software products. I wrote this to share my thoughts with my new team in Boulder. These are processes I’ve found to be helpful but there are many ways to skin this cat.


Before you can effectively build any product you need to make sure that your team and organization has the right processes in place to approve and provide feedback for each phase of the product building process. Meetings are typically the best way to discuss the level of detailed information the product process requires. Smaller companies can get away with less process in general. Keep in mind my perspective is coming from 6 years at a 70k person company.


There are 4 types of attendees in these meetings:

Owner — This is the person who sets the agenda, invites the attendees, and keeps things moving on time. If someone is going over, the owner tactfully requests that they come back to another review or follow up in a different setting. If an audience member is talking out of line, the owner asks them to please hold their thoughts until the meeting is over.

Presenter — This is the person who is presenting their product at whichever phase it’s in. They should come prepared with slides, data, and a clear objective. Their job is to inform the approvers of the current state of the product and to collect feedback/advice on next steps. (Read Improving Your Presentations by Nikhyl Singhal)

Approvers — Leadership representatives from product, eng, legal, privacy, UX, marketing and PR should be in every meeting. Everyone you need to approve your product should be in this meeting. If someone is missing, you will have to chase them down to give them an update and get their approval. If many people are missing this negates the value of the meeting.

Audience — These are the people who do not talk unless called on. They are there to absorb information, not slow things down. If the meetings grow too large and audience members are detracting from the meetings, cut the meeting down to essential personnel only.


The owner controls the agenda. Presenters request time slots a few days to weeks ahead of time. When requesting a time slot, the presenter should include the slides for the presentation, the list of approvers they need to be there, and the amount of time they need. Providing the slides ahead of time allows the approvers to read through them ahead of time which can help speed up the meeting.

The agenda for these meetings largely depends on the type of organization and project that you have. The first 5–10 minutes of the meeting is often allocated to “hot topics” as it’s rare for leadership to all be in the same place at the same time. This is entirely up to your team and can be skipped if there are no topics to cover. It also acts as a buffer if a key approver is late.

The owner circulates the agenda via email at least a day before the meeting starts. This lets everyone work their schedules around the product updates they need to be in the meeting for.

Figuring out how often to have these meetings and how long each should be is entirely dependent on organization. A good starting point is a 1 hour weekly meeting. I like to have this meeting later in the morning (around 10am) while people are still fresh.

Phase 1: Base Principles

When I first started as a product manager I was building for the wrong customer. My manager would come to me with an idea for a problem, told me how he would solve it, and I was so excited to impress him that I would make his idea come to life as fast as possible. Most if not all of those ideas failed.

That is why this step is so critical. Instead of jumping into building some random request, no matter how senior the executive is, go through the Product Opportunity Analysis phase and make sure you and your company should be investing in this.

Most of the ideas you filter through this process will not make it. Presenting this information back to your manager is extremely valuable though. They get the opportunity to challenge your thorough investigation and to review your thoughtful work. After they are satisfied with your conclusion, they will be very happy they did not spend the engineering resources on this.

Going through the POA process gets easier as you get more familiar with a specific market but it will never come for free. If you have a marketing and/or strategy teams in your organization pull them into this process.

Product Opportunity Analysis (POA)

  • Exactly what problem will this solve? (value proposition)
  • For whom do we solve that problem? (target market)
  • How big is the opportunity? (market size)
  • What alternatives are out there? (competitive landscape)
  • Why are we best suited to pursue this? (our differentiator)
  • Why now? (market window)
  • How will we get this product to market? (go-to-market strategy)
  • How will we measure success/make money from this product? (metrics/revenue strategy)
  • What factors are critical to success? (solution requirements)
  • Given the above, what’s the recommendation? (go or no-go)

(POA is from the book Inspired: How to build products customers love, one of 2 books I recommend every PM reads)

Once you’ve answered these questions you have the beginning to your Product Requirements Doc (PRD) and your first deck/presentation to your leadership. It’s important that you present the findings regardless of your go/no-go decision.

Time estimate: 1–3 weeks

Phase 2: Prototype

Your prototype will be used to put in front of users in your target market. It should mimic the functionality of your final product but it doesn’t actually have to function. The look of your prototype can range from sticky notes to beautiful mocks. The closer you can get to the real product the more accurate the feedback will be but keep in mind you will be revising these dozens of times and speed matters. (Google “Rapid Prototyping”)

Present your prototype to leadership. Make sure you are accurately representing the ideas you agreed upon in phase 1. If you have a user research team (UER/UXR), work with them closely on this. Review the plan for collecting feedback from your users. Include dates on when the users will come in, how you plan to recruit users in your target market, and the questions you want to make sure get answered.

Document this plan and link to it in your PRD’s “important docs” section.

Time estimate: 1–2 weeks

Phase 3: User Research

Most UER/UXR studies aim for 6 out of 10 users to find your prototype both valuable and usable before you commit engineering resources to building it. I like to shoot for 7. Eng resources are the most expensive cost when building a product. You want to make sure their time is spent building products you are confident will be worth it.

If your prototype does not pass the 6 out of 10 test, iterate. Really work to understand where the user is coming from and what they are asking for. You may have to throw away your prototype and start from scratch. You may show the users several versions of a prototype to understand which they like more.

Every time you complete a round of research, prepare an update for your leadership. Explain what you found, what users liked, didn’t like, your plan to iterate and the schedule for your next round of research.

If the prototype changes dramatically you may want to walk leadership through it again (repeating phase 2). If it’s obvious what you are going to change and try, skip this update and get back to the users. Either way, update your PRD.

Given that this process is based on how users react to your prototype, there is technically no end to how long it can go. I’ve seen products go through 1–2 quarters of iterations before finally landing on something the users found both usable and valuable. These same products went on to be very impactful solidifying my belief in this process further.

Leadership can get anxious when they hear that a process has an unknown end date. There are a few tactics to calming their nerves and unblocking eng.

Give yourself plenty of time for this process, a couple of months is best. If eng is scheduled to start building your product in Q2, optimally you would start research in Q1. If your company uses the OKR process to track eng efforts, work with your UER team to plan their work.

If you find that eng is blocked on research, break up the product to the parts you know you have to build vs the parts you are still researching. Oftentimes infrastructure work can start before front end design.

Time cost: Unknown

Phase 4: Minimum Valuable Product (MVP)

Once you are through the research phase your PRD should be extremely crisp and your MVP carved out. Present this to your engineering team by sitting in a room and talking them through the process you just went through. Explain the POA, the user research, and how you landed on this solution. Answer the many questions they will have. Work with them through the Scrum planning process to break the product into chunks that your eng team can cost out and build. Your eng lead should take this PRD and begin an engineering design doc.

There may be other teams within your organization that you need to collaborate with to build this product. Include them in your planning meeting to make sure their feedback is included in the design doc.

You will find that your PRD has a lot of information, to the point where it may even feel complete. It’s not. The implementation process will surface new obstacles and decisions that will have to be made. Keep your PRD up to date as these arise.

Once engineering has a proposal that includes timing, costs, and any technical challenges for building the MVP, it’s time to present to leadership. Be ready for leadership to poke on this proposal. There may be features that are expensive in their eyes they they want to cut but are critical to your users. Be ready to supply the right information for the team to come to the right decision.

After you are approved to build your product, use the Scrum sprint process to begin implementation. (Read Scrum: The art of doing twice as much work in half the time)

One key note from the book, the implementation process is not easily estimated. It will be very tempting to tell leadership that you will have the product done by the end of the quarter. Do not do that. Things will come up that delay this process. Implementation details will come up that take much longer than you originally anticipated, folks will take vacations, perhaps someone will get the flu. Estimates for your product are extremely rough and should not be considered final until the code is actually complete. In short, leadership loves Gantt charts but they are always inaccurate.

Time estimate: Unknown

Phase 5: Go-To-Market (GTM) Strategy

While managing the implementation phase, gather all the information you need to successfully launch your product. It’s your job to make sure everyone else knows what they need to do for this product launch.

Bug bashes, Fishfood, and Dogfood, are key to any successful product launch. Work with engineering to get these on the roadmap and share them with the broader team. Typically the more people you have testing your product the better.

Product launches are often rolled out to a small percentage of users first then gradually increased as the code proves stable and the solution usable/valuable. Include these ramp up plan dates in your plan.

Legal, Privacy, and UX should have all signed off by now but if they haven’t make sure to chase them down for their feedback. Work with them as soon as possible as this may change the way that the engineering team actually builds the product.

If you are lucky enough to have a marketing and PR firm, work with them closely on your GTM strategy.

Here are some examples I found online of variables you need to consider. (Google: “Go to Market check list” for more)

Once you have documented your Go-To-Market plan, present it to leadership. Discuss your goals, costs, expectations. Find recent examples from your company or your competition to lean on.

Time cost: 3–6 weeks

GTM Checklist

Launch Plans

  • Launch date is set
  • Communication strategy for launch is approved
  • Launch plan is developed and approved

Post launch Plans

  • Post launch targets are in place
  • Post launch marketing plans in place
  • Post launch analysis and evaluations planned
  • Eng & UX resources secured to address post launch issues
  • Post launch development roadmaps are planned for in product
  • Process to gather feedback from customers defined


Product Development

  • All new components are developed and in place
  • New product is embedded into any existing process
  • Professional and customer services are ready
  • Trials are complete and confident to launch based on the trial
  • Documentation, packaging, user guides, etc., all ready

Customer Experience

  • Customers can find/receive the product
  • Customers can buy/pay for product
  • Customers can get support if needed
  • Customers can cancel or return product


  • Key features and funnels are accurately logged
  • Key logs are easily accessible
  • Non-key features have ways of pulling sudo logs (less than accurate logs)
  • Dashboard are available for systems health
  • Dashboards are available for key feature usage

Product Proposition

  • Overall proposition is clearly established
  • Target customer profiles are identified
  • The product name is finalized and approved
  • The product positioning defined against current portfolio
  • The proposition and key messages are validated with target prospects

Legal and Commercial

  • Customer contracts in place
  • All commercial or legal risks signed off
  • Appropriate commercial and legal agreements in place with suppliers


Internal Communication

  • Plan for communicating launch within Google (launch email? TGIF?)
  • Special events planned
  • Use of product before launch (dogfood plan)

Press and Analysts

  • PR agency is involved (if required)
  • Identified list of journalists, opinions, leaders
  • Press release or press launch is event planned

Marketing Communication

  • Customer launch event is planned
  • Advertising and/or direct marketing is planned
  • Roadshows, user groups, and/or promotional engagements planned
  • Online promotions, press releases, and/or magazine articles, are planned
  • Website updates are in place


  • Demo is available for internal training
  • Demo is available to promote / use with customers

Phase 6: Launch

Launch your MVP following your GTM plan. Be sure your team is present and not leaving on vacation or checking out after launch as you will find that there are areas that need your immediate attention.

Having access to data is essential. Verify that the the software is actually running. Track your key feature user funnels. Watch how users are actually using your product. Dashboards are great if you can get them but queries/tables work just as well.

Communicate your launch internally. Send a launch email to your broader team outlining the first day of findings. Send an update email to your broader team 1 week after launch recapping all of the early data, insights, press, user stories, feedback, etc. Once the launch is showing consistent data, review this with leadership to define the v1.1. Include an update about this launch in an email update at least once per month

Timing cost: 1–4 weeks

Phase 7: v1.1

Once your product is in the wild, it will be obvious what is working and what is not. Several areas will be highlighted through data and user feedback that you can improve. Jump on the low cost improvements as fast as you can. Show your users that you are paying attention.

Other more expensive, less clear areas of feedback may require longer term investment from engineering, UX, and prototyping.

Have a team’s celebration planned. After the v1.1 is launched, it’s typically a great time to schedule vacations. Make sure that people aren’t switching onto other projects too fast and that they take a break in order to avoid burn out.

I like to consider v1.1 as the “end” of the first launch cycle. Once you have completed this you can repeat this process to iterate on your product.

Timing cost: 2–4 weeks


I hope you find this helpful.

I’m very open to feedback, comments, questions, horror stories, and to learn together.

-Loren Groves