How to Build a Core Team That Can Scale as the Product Grows

SEARCH THE BLOG

SUBSCRIBE NOW

Receive tech insights and tips from Augusto

3 Tips for Transitioning to Remote Work

 

core-team.jpg

 

Continuing on in our series about the real software investment, I’d like to share some advice on how to put together a core team that can scale as the product grows.

At Augusto, our goal is to influence our clients’ mindset regarding investing in software, so that the products they build for their audiences solve the right problems and achieve growing adoption. That’s why we coach clients to remain agile and invest smarter. We’ve learned that the real learning begins after you release the product into the marketplace.

This same message applies when establishing a core team for the product. Ignore the tendency to focus the budget conversation on the scope or on creating a fully-fledged team right away. Rather, identify and focus on the key players you need to create an MVP.

Composing the Core Team

The key roles for a product team often depend on the budget and size of the project. To be clear, there isn’t one single definition for these roles. You may see them used in different ways. They may be two separate roles, or one person may be responsible for the work of both titles.

But I’ve found that a product manager and a product owner are two of the most important roles to get right early on. In a small team they could be the same person, but finding someone who is strategic and someone who can execute the tactic details can be challenging.


Core Team Product Manager@2x.jpg

Product Manager

The product manager has a view on the overall success of the product. Product managers are strategic. They focus on the product’s vision, company objectives, and market. They’re focused on questions like “Where does the product fit within the organization for whom we’re building it?” “How do we know what success looks like from a business standpoint?” “Will this create a quantifiably better user experience?”

The product manager guides the success of a product and leads the cross-functional team that is responsible for improving it. They define the why, what, and when of the product that the engineering team builds. Essentially, they own the vision, continually identifying the activities necessary to bring the product to market.

The product manager creates a roadmap to prioritize activities and outlines the timeline for delivery. Then, the product owner works with the engineering team to ensure that they’re building the right experience.


Core Team Product Owner@2x.jpg

Product Owner

Product owners are more tactical. They translate the product manager’s strategy into actionable tasks and work with the team to make sure they are executing on those requirements. The product owner executes the details; making priority decisions based on the product roadmap and detail requirements. Additional roles may include a combination of a PM, technical lead, UI/UX architect, designer(s), engineer(s), business analyst, and QA tester.


Estimating the Cost of the Core Team

When we talk about estimating the cost of the core team, we’re discussing strategies to eliminate risk.

For each team size option, you can estimate their operating cost per sprint. Start small, commit to a few sprints, then conduct demos. This is an easy way to learn what you truly should build, allowing you to then reevaluate who is needed on your team.

The most important point is that you need to build something early. Throughout the process, develop a common understanding of the problem(s), the business outcomes you’re aiming for, and your measurement tactics. These questions should help you focus on building the right product for the end-users, also helping you define the relative size and scope of the product. From here, you’ll be able to build the team up over time.


Building the Full Team Over Time

Start by tying your product roadmap to the highest level business capabilities.

A roadmap is a tactical visualization of your strategic plan, informed by vision and strategy. It’s not static.

Working in six-week release cycles, begin to identify specific goals for the immediate next 6-12 weeks, while maintaining broad themes for each subsequent period of time. For example, you might decide to spend Q2 focusing simply on the broad theme of mobility. The reason for setting broader goals when communicating to stakeholders is that software changes so often. You want to create excitement without pigeon-holing yourself to the point that you fail to meet expectations.


Augusto’s Collective Experience

Collectively, Augusto’s staff has over 100 years of experience in helping product managers and visionaries organize and approach products with a product mindset rather than a project mindset.

The difficulty in software isn’t the actual process of building, it’s identifying the right product to build. At Augusto, we focus on excellent product engineering, while always focusing on the business outcomes the product needs to achieve. This mindset drives us to identify the riskiest assumptions and hit them head-on.

We’re skilled at providing a realistic estimation of the relative size and type of team you’ll need.


We start our engagements with an intro call. Schedule one today to learn more about how our approach may apply to your business goals.

 

Sign Up For Our Newsletter

Stay up to date on the latest news, insights and offerings from Augusto.