How we are becoming a product-led company
A few months ago, I had a great conversation with Justin Bauer, the VP of Product at Amplitude, about the future of business-to-business (B2B) software companies. B2B software companies have entered a new era: the era of Product-led Companies (PLCs). Justin and I were talking about how in the 1990s, many of the market leaders in the B2B software industry were sales-led companies. A decade later, we saw a shift to a marketing-led model. Today, we’ve entered the era of product-led companies (PLCs).
A great product can increase a company’s retention and lower customer acquisition cost. PLCs have a different approach to engagement: product is their distribution center, product is their competitive advantage, and product is their driver of customer loyalty.
For marketing, customer success, sales, and product teams to work in blissful harmony in PLCs, all the teams must rethink their process from a PLC’s point-of-view. This point-of-view can be established among all the teams using the following approach:
- Identify your product’s critical event
- Understand the real problem: customer-driven product development
- ICE your product roadmap
- Plan a series of Lean UX sessions for cross-functional collaboration
- Demo early, demo often
Identifying your product’s critical event
It’s hard to resist new ideas, and new features — the allure is intoxicating. One effective way to resist that allure on a company level is to establish a critical event: an action that users take in your product that aligns with your core value propositions. A critical event gives everyone something measurable to focus on. “Focus” is severely underrated and incredibly hard for teams to embrace. At CrowdRiff, we’ve resisted the light of shiny new ideas by establishing our critical event and sharing it with the entire company.
Our critical event at CrowdRiff is the number of actions our users take on each visual content they view (i.e. the value our users capture when they go through their CrowdRiff’s digital asset library). Every new feature we build has to either increase the number of possible actions our users can take on each viewed item or decrease the number of items our users have to view before they take an action.
A critical event is an action that users take within your product that aligns closely with your core value propositions — the action you want to drive your users toward.
Similarly, when it comes to enhancing our existing features, we are laser-focused on improving them in a way that we will increase the number of actions our users take on each visual content they view. We focus on delivering innovation around our critical event every day. And, when we are asked to build a new shiny feature that deviates us from focusing on improving our critical event and product’s bottom-line, we can reject it because, as a company, we have already established our product’s critical event.
Understanding the real problem: customer-driven product development
Customer empathy means everything to us at CrowdRiff. Our CEO Dan Holowack wrote a fascinating article a few weeks ago about “when to say yes to customers”:
The general notion in product management is that, as a PM, you should say ‘no’ a lot. However, saying ‘yes’ in the early stages of growth is vital to creating a strong value proposition for your target market. Saying ‘yes’ to our early customers helped us build a product that is currently serving all the top Destination Marketing Organizations (DMOs) in the world. We built a product that serves the main visual marketing needs of these DMOs.
Now, we are working to optimize our product; adding even more features to our platform to enable our customer “see what matters” every time they log into CrowdRiff. Evidently, at this scale, not all feature requests can be built at once. However, through the use of a central research repository that allows us to store all our customers’ requests, we can process, prioritize, and build each feature when the timing is right.
At CrowdRiff, every single customer request, every Intercom conversation, every Zendesk ticket, every call with a prospect, and every NPS result comes to our product team. Once we receive these requests, we tag them based on the nature of the request. If we have similar feature requests they are grouped together in the repository; otherwise, we create a new group for it. This approach allows us to spot trends and identify patterns. Every month, we review our repository to decide what to build next. Our customer requests heavily shape what we build each month (more on this in the next section).
Our customers use our product every day and like other B2B products the more value our customers get from our product, the faster we grow. Since we started building our product roadmap based on our customers’ feedback, we’ve started noticing a lot of patterns in what we are planning to build, and what our prospects are asking for. During the last 2 months, a substantial portion of feature inquiries coming from our prospects has already been planned and added to our roadmap based on our customers’ feature requests. It’s impeccable that you can build a great product when you trust your customers and take their product feedback to heart.
ICE-ing your product roadmap
At CrowdRiff, we evaluate every new feature and feature improvement request using the ICE (Initiative, Confidence, and Effort) model. Each item in our product backlog receives an “initiative” score, a “confidence” score, and an “effort” score. We then add them up, sort them by score, and use them to build our roadmap for the quarter.
Initiative
At the beginning of each quarter, we set our OKRs for the quarter. Every item we have in our product backlog gets scored based on its impact on the initiatives we’re focusing on for the quarter (e.g., revenue, retention, internationalization, etc.). A feature can score really low this quarter, but can score really high next quarter — if it aligns with our next quarter’s initiatives.
Confidence
Building features based on anecdotes is the worst mistake you can make as a Product Manager. Product Managers of product-led companies have to use data to make decisions. When you are evaluating the impact of a new feature on your OKRs, you should factor in your level of confidence about your estimates. If you think a feature could have a huge impact on your next quarter’s initiatives, but don’t have data to back it up, the confidence score keeps you in check. At CrowdRiff, we rely on product analytics and customers’ feedback to calculate our confidence score. After gathering an understanding of the problem from multiple customers and seeing how it applies globally, our product team can determine how confident we are about the impact of a feature.
Effort
Last but not least, we always factor in the level of effort required to build each item in our product backlog. We have an amazing scrum master at CrowdRiff that coaches our team to come up with realistic estimates for every project. We always want to deliver the maximum amount of value to our customers with the least amount of time and resources spent on building the solution. Solving this optimization problem yields constant value creation for your customers.
By implementing the ICE model, our product team continuously strives to develop, direct, and deliver a better product. We have built a product team that interacts with the customers directly, uses data to inform product discovery and understand our user behaviour.
Planning a series of Lean UX sessions for cross-functional collaboration
Product-led teams do not seek consensus. CrowdRiffers fight and unite. We debate the issues, consider alternatives, challenge each other, listen to minority views, and let the best ideas win. Before we build a major feature or improve a key feature, we plan a series of Lean UX sessions (i.e. brainstorming sessions) prior to solving the problem we’re facing and finalizing our product design. Lean UX sessions are focused on the experience under design and are less focused on deliverables than traditional UX. Lean UX sessions require a greater level of collaboration with the entire team. For each Lean UX session, we bring in one member from each team: sales, marketing, customer success, finance, and engineering. If you want to excel at solving interdisciplinary problems, you have to invite a diverse group of people to your brainstorming sessions. In many companies, I’ve noticed product teams or engineering teams end up solving the problems among themselves without running their solutions by other teams. And, that’s a big threat to building a product that is over-engineered and has numerous UX issues. If your product/engineering team works on all of the same projects together, goes to team meetings together, sits next to each other in the office, and hangs out in the same group chats all day, the ideas will likely start to get pretty homogenous. We invite new people from other teams to our Lean UX sessions — people with different skill sets and experiences to get us out of our rut and see things in a new way. Our Lean UX sessions have given us the great mix of new perspectives and contextual knowledge we need as a product-led company to land on ideas that are both original and elegant.
Demoing early, demoing often
Every Friday afternoon, we host a company-wide meeting to share a recap of what happened over the week with the entire company. It can include anything from what’s happening with our product to what we learned from our mistakes or technical issues we are facing. We share our Lean UX results and demo what we have designed or built so far. We never wait till we’re fully done before we share the outcomes with the rest of the company. We always default to full transparency in how we are designing our product and building new functionalities. We feel comfortable and excited to share our learnings. It helps us get more feedback about our decisions. One of the business books that has had a large impact on me since I’ve started leading product teams is The Five Dysfunctions of a Team. Transparency breeds trust, and trust is the foundation of great teamwork. For us, we’ve found that transparency is a great way to build trust at CrowdRiff. If you regularly articulate all the information about your product decision making process every week, you help everyone feel involved and on board with the decisions you make as a team. Product-led companies believe that being open helps them build trust and share their reasoning for the features they have, the pricing decisions, and many other choices.
Get on the rocket ship
The above approach has given everyone at CrowdRiff something measurable to focus on. But, more importantly, it has enabled us to build the features that delight our customers and attract prospects.
We are solving the hardest problems in visual marketing by using Big Data and Artificial Intelligence. We are moving fast and we are hiring 🚀 Get on the rocket ship: https://goo.gl/bxwUCS
