Best practices to scale a Product team

I joined Activate Care at a time there was very little Product discipline for the startup. The VP was very strong in the social care domain, but she didn’t have a technical background. The development team was releasing every week, leaned on Product for QA, and was responding to whatever customers and Sales asked for. It was an overwhelming experience for my manager, and I was hired to help establish Product best practices and operations as the company was planning for a growth phase.

Considering the team was made up of me, a very junior employee, and my manager, I quickly realized there needed to be a lot of new processes in place. I created and executed: standard requirements templates, regular kickoff meetings and updates with stakeholders, and more than a week between releases to have any success. The artifacts below are operational, but allowed me to hire and scale up the team while keeping an eye on the Product Strategy we needed to execute.

Product knowledge Base

One of the first things I set up was a knowledge base in our Notion environment as a library for the team. I created templates for project kickoffs and documentation, as well as linked to some of my favorite articles and books for the team to reference.

I also created and recorded presentations on how to do Product in Agile/Scrum, write executable acceptance criteria, and methods to prioritize the backlog and roadmap.

This library was easy to find, and was a helpful tool to onboard new members of the Product team. Over time, my team started contributing to it as well. It ended up as the go-to source of knowledge on Product best practices that Activate Care followed.

Product Requirements

I realized that we needed standardized requirements to help cut through the chaos. In our small team, we had different styles of how we were wrote requirements. As we were transitioning to an Agile process, aligning on how to write Acceptance Criteria was important to reduce confusion with the Development teams.

I pulled from the best practices I used at Allscripts/Careport and presented on User Story guidelines to the team. I proposed the INVEST framework (see image), and highlighted the Gherkin writing style: Given, When, Then.

I was able to get alignment with Development and UX quickly when I proposed this for User Stories. It reduced confusion and friction when stories were estimated, and it allowed me to onboard new team members quicker.

Product kickoffs

Writing User Stories are important, but explaining why a project is being picked up is more important. I have learned through my experience that explaining the “Why” is more important than the “What”. Explaining the “Why” highlights the problem that is being addressed and how it will impact the customers and the business. It reduces friction and frustration from Engineering teams that question the value of their work. It also allows teams to focus on the problems, as opposed to being told what to build.

I used two artifacts to help me tell the story, get teams and stakeholders aligned, and stay on track to the project goals. The first stemmed from the Positioning Document from the Pragmatic Institute. The document was used as my “North Star” on prior projects and it helped me organize my thoughts and what needed to be shared with stakeholders. After some collaboration with the UX and Engineering leaders, the document evolved into a Notion Project page that provided all the “What” and “Why” details needed to kickoff development. Doing this on Notion not only allowed teams to track the progress, but it was a living document that continued to guide what needed to be built.

But not everyone wants to read all of the details, and the non-technical stakeholders had to focus on their jobs. I created a slide template to kick off projects for all parties involved. It pulled information from the Positioning Document and the research that was done to justify the project. The slide deck was easier to consume in a 30-60 kickoff format. Additionally, I recorded the sessions so they were easy to point to and share later.

Both artifacts helped to streamline the discovery and definition process. Even in an Agile environment, I find it important to know why a project is important and have funtional requirements identified before coding. Things will shift as a project continues, but a solid story going in keep things from going off the rails completed.

Career Path

The strategy in my first year at Activate was to add Product Owners to fill in the new development Pods, as well as add another Director to lead the strategy on integration efforts. My VP started a document to set expectations on various competencies at different experience levels in Product. I evolved it and continued to use this for Product level expectatiosn and setting career paths.

It was important to share and set these expectations of the team, so they had more clarity on what was expected of them. Product people are hard working and ambitious. They need to know there is a growth plan, even in a start up. Having this document made it easier to set individual goals, facilitate objective reviews, and write clear job descriptions as the team grew. Transparency is important to me as a servant leader and this document served me well to evaluate the talent on my team.