In our previous blog post, we discussed the foundations and best practices for managing developers for non-technical managers. Today we’ll broaden the scope and give you our best tips and tricks for managing your entire product organization (part 1 of 2).
Once again, this article will help you lay the groundwork for success even if you don’t have any technical background. When you implement the points and steps here, you’ll be able to effectively manage your product team for results.
Before we dive into the details, however, let’s take a step back and briefly discuss one essential process that can make or break your entire organization – innovation.
How to Innovate the Right Way
Innovation is the cornerstone of any successful startup and developed company that wants to stay competitive in the market. But how do you approach innovation?
Should you give 100% creative freedom over everything and hope something amazing comes out of the chaos? Or should you perhaps have a rigid step-by-step system for innovating while risking creative constrain? As with most things, the truth is finding the right balance.
Here is our Co-founder and CPO, Boris Borisov’s take on the subject
“I would recommend innovating in the product (where innovation is needed)… But not innovating how the work is being done. There are plenty of best practices that are widely accepted in the industry. Diverging from the best practices should be done purposefully, from a position of deep understanding.”
As you can see, unless you have plenty of on-hands experience working in product teams and managing them, the optimal thing you can do is stick with the best practices. You can give creative freedom to your product team in the early stages of ideation, but then it’s best to follow a well-defined process.
Now that we have given this important disclaimer, let’s jump into the details of managing your product organization.
Best Product Teams Structure
The product organization consists of two teams – or at least two separate workflows.
1. Discovery team – tasked with figuring out what needs to be built.
- Product Manager (PM) – typically the team lead
- Designer
2. Delivery team – tasked with building it.
- Engineering Manager (EM) – typically the team lead
- Developers
Note that the two teams collaborate frequently. For example, the PM communicates the tasks that need to be built to the EM. The EM, on the other hand, can help the PM with the Engineering perspective on things – such as estimates on the timeframe to build different features. Often, the Delivery team may need some additional designs from the Designer when they get to the building of a task, etc.
At an early-stage product team, sometimes you see that the PM is doing both the PM work and the EM work. But this is not recommended, and well-resourced organizations wouldn’t do it. That’s because the EM work and the PM work are both pretty much full-time jobs, even for a small team of 3 developers and 1 designer.
It’s important to note that all of this applies to both on-site and fully-remote product teams.
In the next section, we’ll discuss the article’s main topic- organizing your Discovery team and workflow.
How to Organize Your Discovery Workflow
Everything starts from the Business Strategy of your company, which is usually crafted primarily by the CEO. Then, only after you have your overall strategy, you proceed with making the Product Strategy. Usually, this task is done by the PM (CPO) in collaboration with the CEO.
The two main questions you should ask when building a Product Strategy are the following:
- What are the goals of the product organization? For example, what KPIs should the product hit, and over what timeline?
- What resources do we need to achieve this?
Of course, you need to define some very important sub-questions, such as Product Vision, Customer Persona, Competitor Analysis, Market Analysis, etc.
After you complete the Product Strategy, you can process to create the Product Roadmap. In most cases, this PM handles exclusively this task, but still needs to have a broad buy-in across the relevant stakeholders. The Product Roadmap should include big-picture initiatives – such as “in this Quarter, we need to introduce candidate sign-up flow”, etc.
After you have these essential pieces in place, you can begin executing, and the Discovery Workflow begins. Ideally, you should have a pre-defined timeline – e.g. 2-week Discovery sprints.
Prioritizing Your Development Ideas
You need to prioritize ideas (regardless of the source) based on expected impact vs. cost. Once the ideas are prioritized, the PM makes a plan on how to de-risk the highest-priority ideas. Note: de-risking is actually a more resource-intensive process than it looks at first. That’s why a lot of teams skip this step. If you have the resources to do de-risking in parallel with the other things going on in the team, it is definitely worth doing it financially. For this to happen, the rule of thumb is that the PM needs a minimum of 20 hours per week solely on Discovery work and ideally >40 hours per week (for a team of ~5 developers).
In most cases, part of the de-risking is to make designs of the features (the PM in collaboration with the Designer), and then talk with the users about the designs. But there are also other ways of de-risking, depending on the type of risks involved in the feature – desirability, feasibility, viability, usability, and so on. To give an example – maybe the feature could be more technically feasible or business viable.
At the end of the Discovery sprint, there are features that are validated/confirmed for building and sent to the Delivery team for building. In our next article, we’ll examine exactly how to organize the delivery workflow. Until next time!
P.S.
If you are interested in some of the parts of this topic – our CPO loves to help people with this type of questions. Feel free to connect with him at boris.borisov@remotemore.com.
