How to Create a Product Process from Scratch
I recently joined a new organization, Dozuki, as product manager. My role is the first official product management role they have hired for, and the product management duties were previously done by the CEO. At the time of my joining, no defined product management processes had been put into place, and it was up to me to create them.
Creating product processes from scratch is an exciting opportunity. You get to really do your best work and put your mark on an organization that has so much room for improvement – any organization without a defined product process likely has a ton of room for improvement.
In this article, I’ll talk through the steps you need to take to get started on your product process:
- Gather info about current processes
- Understand the product
- Understand your customers
- Understand the business
- Create a roadmap (aka prioritization schema)
- Make adjustments
Gather info about current product processes
Even if there is no defined product process, the team likely has some method that they generally follow to get things into the development pipeline. It’s your job to document this process and start using it. Here are some questions you can ask to start understanding the current process:
- What is the general product process at Dozuki? Describe to me how it happens.
- Requests, bugs, and research
- How are requests and issues from CS, marketing, sales, and other departments recorded?
- What customer survey tools / techniques are currently used?
- How are new feature ideas generated and tested?
- How are customer requests and bugs currently prioritized?
- How are new features currently prioritized?
- How are bugs currently prioritized?
- How are tech/platform improvements currently prioritized?
- Github / Jira / YourToolOfChoice
- How are new issues created and triaged in Github/Jira/yourtoolofchoice?
- How are user stories currently crafted and presented?
- What level of detail is expected for issues when they are spec’d out?
- What are the current business goals? What’s the highest priority one?
- What KPIs are tracked and used? How are those visualized?
- How is app usage tracked?
- What is the definition of “done?”
- Does the team use persistent personas?
- Where does design fit into the process?
- What promises have you made to any important stakeholders?
Understand the product
As you work through the questions above – and any others that pertain to the business individually – it’s important that you get in the mindset of your users. You must be one of them as much as you can.
Hopefully, your organization is dogfooding – using their own product in their daily lives (if B2C) or to run their business (if B2B). Even if the product doesn’t help for your role specifically, find an area where it might and jump right on in.
For example, Dozuki is a documentation and training platform for manufacturing companies. While we’re not a manufacturing company per se, we still have tons of processes we need to document. In addition, when one of those processes changes, we need to make sure everyone who is responsible for executing on that process is trained on the new method. We use our own platform to achieve these goals, and in doing so we uncover bugs, ideate on new features, and “feel” the user experience just like our customers would.
Understand your customers
While understanding the current product is incredibly important, understanding your customers and how they use your product is even more so.
Understanding your customers is the only way you can make meaningful, valuable changes to the product.
There are a number of ways to go about this:
Talk to customers directly
The very best way to understand your customers is to talk to them. A lot. In getting to know your customers, you can get in their shoes and feel their pains. You can see where they struggle and where they succeed. You can feel empathy for the work they do.
All of this is incredibly important. It is best achieved by visiting the place where they use your product – in their offices, on their manufacturing floor, at their construction sites, in their homes. In this environment – in their environment – they will be most comfortable and most likely to give you valuable insights.
If your customers are far away, you can jump on a call with them. While calls – even video calls – are good, they are more likely to move away from the tangible, real-life and into the theoretical. Theoretical conversations are good to have, but they tend to lean toward what the customer thinks s/he knows about her/himself. The more concrete, in-your-environment conversations and experiences let you see things about the customer that s/he doesn’t even realize about her/himself.
Run an importance vs. satisfaction survey
Dan Olsen’s book The Lean Product Playbook describes how importance vs. satisfaction surveys can help identify areas with a lot of potential for value creation.
Areas that usually have high potential for value creation are those with high importance but low satisfaction.
The surveys help elucidate, with data and numbers, what will provide more value to customers as compared to other areas. It helps eliminate the noise of other low-satisfaction areas that are tempting to devote effort toward but that might not actually move the bar in terms of value provided.
These surveys can be run for:
- Areas that already exist inside the product to see what needs attention
- New areas tangential or parallel to your existing product to see what new features might be valuable
The results from these surveys can be incredibly helpful in starting to define a discovery roadmap – not a development roadmap, but a roadmap of things that you’d like to explore for better solutions.
Listen to sales calls
This one is on the list because they can be valuable; however, they can also be very misleading. Sales calls can help you understand why prospective customers decide to not move forward with your product, which might help you understand your weak points.
However, it’s important to not get distracted by things that prospective customers want that aren’t actually in your core value proposition. Superhuman built a product/market fit framework that focused only on high-expectaiton customers who would be very disappointed to not use their software again. If they had focused on prospective customers who didn’t convert in determining their featureset, they would not be where they are today.
So in short, listen to sales calls, but use them carefully and wisely.
Understand the business
Objectives & Key Results
If we all made products that only satisfied customers to the n-th degree, we wouldn’t have a business. We’d all be making free products – because using something for free is better than paying for it if the service is the same. And truly free products don’t employ people, don’t have the support they need, don’t work for the long-term.
Our products have to serve our businesses.
It is imperative that the product manager understand what the high-level business goals are and how progress against those goals is being measured.
OKRs – Objectives and Key Results – is a framework that helps define what the company objectives are for the next few years and how progress is measured. I’m not going to go super deep into this framework here, but you can read more about it in this in-depth article.
The important thing here is that, as a product manager creating a product process from scratch, you need to be able to coach your executives through this process of creating OKRs. You cannot effectively prioritize product work without understanding what the North Star of the business is. It is your job to uncover these OKRs with the executive team.
If your team has OKRs or some comparable framework in place then you’re already a step ahead. Scrutinize the objectives, ask questions about the key results, really understand why it’s important and how your product will move the needle toward reaching those goals.
Serving other departments
If your company is small, you may only have one product team that needs to serve your customers and other internal departments. If this is the case, it’s very important to understand how your product needs to serve these other departments. Ask questions of each department head:
- How do you generally feel about getting your product needs met?
- What does the process usually look like for you when you need something done?
- What frustrations have you experienced with this process in the past?
- What has worked well for you in the past?
Serving other business departments well is imperative for your product – and your business – to succeed.
A product process that hasn’t been well defined or scrutinized usually has a lot of room for improvement. After doing the initial research into the existing process, the product, the customers your product serves, and the business, you will see some areas that could use improvement.
Start with the small and easy ones and move up from there.
For example, one of the first things I did after starting at Dozuki was improve communication between other internal departments and the product team by opening up a feature request board (we use Canny) where they can put their requests. This helps them feel like their requests aren’t getting lost in the mix, even if they take a little while to complete.
Create a roadmap (aka prioritization schema)
I know, I know. Roadmaps get all sorts of flack these days. That’s because if they’re used incorrectly they can be anything from not helpful to entirely disastrous.
But we still need a way to keep track of what’s coming down the line. I call this a prioritization schema – something akin to a roadmap, but without all the hatred from dev and product teams due to bad history with roadmaps.
Your roadmap / prioritization schema will take everything you’ve learned into account and will help you determine where to place your development efforts. I’ll be publishing a new article soon that talks about how to craft your prioritization schema. Until then, I’ll leave you with this formula:
Relative ROI = Customer Value * Opportunity Cost * Confidence * Alignment with Business Goals / Difficulty
Your email address will not be published. Required fields are marked *