Sanjoy Singh
Kevin Rose, the co-founder of Digg and a venture capitalist, once said, “A team aligned behind a vision will move mountains.” This statement is true. To build a successful product, you must navigate through uncertainties, and to do that, you will need a clear product vision.
When you have a development team aligned with the product vision, communication becomes easier, and there is lower dependency on key stakeholders, as it empowers team members with decision-making ability. Such teams think more about improving feature adoption, customer engagement and delivering product-centric outcomes, which reduces iterations and production cost, refines time-to-market and helps in achieving business milestones.
Just consider the COVID-19 pandemic. Startups suffered due to communication overheads, high attrition rates, reduced morale and battled productivity issues.
TechCrunch+ is having an Independence Day sale! Save 50% on an annual subscription here.
(More on TechCrunch+ here if you need it!)
However, startups with aligned product teams maintained their productivity and inspired innovations just the way they used to do, because they understood the “why” of building a product.
I have built about 30 startup products over the last 16 years and managed product teams as small as three people to as large as 150. Based on this experience, I have created four rules that I always follow to keep my product teams aligned with the product vision.
Map individual aspirations with product needs
The success of a product depends on the commitment of the team that builds it. In order to achieve milestones, you need talented individuals who are as committed to the product vision as you are, or you might end up with people with skills but no sense of ownership.
To prevent that from happening, you should look at the aspirations of each individual and compare it with what the product needs. You have to maintain a fine balance between the two to improve the grade of the team without compromising an inch on the level of commitment.
This is what I do during my interactions with developers. I always try to understand what developers want to do and how they see growth.
I often get feedback along the lines of:
- I want to learn the bootstrapping process.
- I want to learn about new technologies.
- I want to handle the scaling of a product.
- I want to become a full-stack engineer.
- I want exposure to an architectural pattern like Microservices.
Keeping track of these aspirations and addressing them makes it easier to build product teams with high morale, high engagement and better alignment with the product vision. At the same time, individuals start cultivating a sense of ownership of the product. Such teams do not get affected by uncertain times and face minimum attrition issues.
We follow this rule like a commandment and reap its benefits all the time. In fact, we did this while working for one of the world’s biggest mobile advertisement platforms, and we faced zero attrition over four consecutive years.
As startups evolve, they sometimes revise their product vision. To stay on the same page, it is necessary to map skills, experience and aspirations at regular intervals.
Follow product mindset principles
“Product mindset principles” are imperative for startups and growth-stage companies, as they ensure strategic outcomes over product delivery. Startups that only build features may find achieving milestones difficult, but they can expect favorable outcomes if they adopt a “product mindset.” Their roles should cover two distinct sections: must-dos and should-dos.
The must-dos include commitment and delivery, solving technical problems, design with short-term agility and first-time-right methods. On the other hand, the should-dos include managing scope creep, better feature adoption, innovation and ensuring architectural longevity.
Achieving these objectives requires the proper mapping of user stories, understanding how users will interact with the feature and how the feature will add value to product KPIs before they push features to production.
Adopting the “product mindset” changed things considerably for us. We now ask for user stories to understand the product requirements better, develop features collaboratively and prioritize feature adoption over shipping features as per the specs. Product owners are responsible for feature ROI, but asking the right questions can help you understand the end goals and plan technology execution accordingly.
Let me share an example that convinced us to change the way we work.
Like most software companies, our developers used to focus on quickly rolling out features based on the specifications mentioned without focusing much on the usage pattern of the users. But after some internal discussions, we decided to check how those features impacted the users. We were aghast to find that the majority of users never used 60% of feature functionalities, because they were not aware of them.
On a different occasion, we found that our developers wasted their efforts in building a feature that only 10% of the targeted users utilized.
Questions to ask to build a better user story:
- What issue will it resolve or benefit it will add?
- Who will use it?
- How will it be used?
- How will it contribute to business KPIs or product KPIs?
Then, to make the impact of the feature more holistic, we should start asking questions about feature usage:
- Is it solving the problem?
- What is the adoption rate?
- How many are using it? Who is using it? How are they using it?
- How much improvement in business KPIs and product KPIs?
- What are the possible enhancements required in the future?
Having a “product mindset” is a necessity. It ensures efficient utilization of engineering bandwidth, impactful outcomes and a real sense of ownership — things required to keep your product team motivated and aligned. If executed well, this mindset makes innovation a way of working and not just a one-time activity.
Align business outcomes with team KRAs
Setting KRAs should be top-down, and it should not be just about delivery. Instead, business outcomes should drive product team KRAs.
I learned this the hard way: Our people completed their individual KRAs while working with a customer, but we realized that those KRAs had not helped us much in securing the desired impact. Such incidents might trigger a false sense of achievement at first, only to lead to dissatisfaction, confusion and low morale in the team later.
Afterward, we transformed the way we functioned. We started mapping the competency rating of the team as per the product KPIs and discarded activity level KRAs for individuals. This helped us ensure that individual KRAs were aligned with business outcomes. As a result, we observed a massive increase in the engagement levels of team members. They now show high ownership and commitment to drive an impact through their work.
For instance, one of our online advertising customers was trying to improve their bottom line. We brainstormed and set up KRAs to automate processes, reengineer the product and improve ad targeting, which eventually reduced their technology infra cost per ad transaction by 15%.
I use a four-step process to define team KRAs for a cycle:
- Talk to business owners and understand their priorities.
- Understand the business roadmap for the next three months, six months and one year.
- Align the product roadmap accordingly.
- Set KRAs for the team with the business priorities and product roadmap in mind.
These rules are essential to keep individual KRAs aligned with business KRAs. When they are in sync, the team’s morale increases, individual contributions add value and outcomes become more impactful.
Ensure seamless communication
I do not recommend a single point of contact for the management of the product vision. It can make product vision myopic and throw team priorities and business expectations out of alignment. Technology could remove such issues to a considerable extent, but if you want to improve the process significantly, you must initiate periodic touch points across the hierarchy in addition to many-to-many communication.
Startups are especially prone to misalignment issues due to fast-changing business scenarios and their inclination toward agility and speed. Periodic touch points and many-to-many communication are critical to ensure that any change in the short- or long-term business goals is efficiently conveyed to the product team.
In most distributed work setups, there is only a single point of contact. I use a three-level touch point model, which inspires a collaborative work culture that enables team members to bond with each other, feel free to share their opinions and suggestions and have their doubts cleared by any member of the extended team.
Day to day
Usually, a team lead who owns the delivery part interacts with their counterpart or superior to groom user stories and ensure timely delivery and quality of the features. They ensure these through scrum meetings, show and tells, all hands and roadmap discussions.
Monthly
An engineering manager who focuses on product roadmap connects once a month to check if the team is aligned with the short-term goals and defines a product roadmap for the next one to three months. They also track feature delivery and adoption, product metrics, identify risks and suggest improvements.
Quarterly
The CTO or someone from the technology leadership team connects with the product team once a quarter. This person ensures that the team understands the product vision, sets priorities for the next three to six months, checks on major release timelines, shares new ideas and updates business KPIs.
This three-level touch point model is quite effective for managing changing business expectations and keeping the team aligned with relevant outcomes.
Ensuring many-to-many communication creates an environment of open discussion and efficient utilization. Individuals should be able to reach out to anyone if they face any issues, need any clarification or have any suggestions. Such an open environment acts as a catalyst for innovation and motivation.
Comment