In an increasingly competitive SaaS market, product development and engineering is a critical component of success among organizations looking to make their mark. Of course, this is often easier said than done. SaaS businesses of all sizes face unique and dynamic hurdles as they attempt to build, promote, and evolve their offerings, especially in the wake of new remote protocols and growing complexity in areas such as security and compliance. Success rests upon a given enterprise’s ability to gauge the demands of their customers, the market, and their own internal benchmarks. Having seen the challenges so many businesses face with regards to this subject, Amazon Capital wanted to cut to the heart of why some organizations emerge victorious while others falter. That’s why, on December 9th, we hosted our second CEO Roundtable entitled “Efficiently Scaling Product Development for SaaS Companies.” Over the course of two hours, we presented two keynotes from speakers Claudia Dent and Ryan Breen. Moderated by Akmazo Capital’s own Imad Mouline, this event yielded rousing discussion from all in attendance, speakers and audience alike. Here are some of our key takeaways!
The Nuances of Product ManagementAs Claudia Dent put it at the beginning of her presentation, product marketing is an art as much as a science, with multiple pathways to success. Nonetheless, there are a few best practices that are wise to follow in order to achieve the most from one’s product lines.
Compelling VisionAt the core of any product line, there must be a compelling vision that is
- Enduring and scalable
- In-line with market demands
- Resonant with your customers and your team
Balanced InvestmentsA crucial consideration when it comes to product management is being able to balance your investments across your offerings. A critical component of this involves effectively doling out resources for both Core and Context factors, first put forth by author and consultant Geoffrey A. Moore:
- Core (60% of resources) refers to the features of your offering that offer substantial differentiation from other products in your target market, and allow you to push premium pricing and achieve increased volume.
- Context (40% of resources) refers to the aspects of your product that are expected by your customers. Managing these involves things such as uptime or support availability.
Actionable RoadmapThis is where your actionable roadmap comes in. Product development and management is complicated and knotty. In addition to vision and investment questions, this roadmap should consider a number of factors for prioritization, including:
- Sales blockers
- Adoption blockers
- Vertical solutions
- Sales channel challenges
- Competitive differentiation
- The potential for new buyers, sales motions, and technologies
- Marketing and sales
- Account management
- Product engineering
Measured OutcomesWhen you think about the question of balanced investment, you have to ask yourself: what are the outcomes that you expect? If you don’t have key metrics in mind for how you measure the success of a product, it’s impossible to effectively gauge success. These measures can include:
- Acquisition of new logos
- New bookings targets
- Renewal targets
Feedback and ChangesThis is perhaps the most important of these six for long term success. Things will inevitably have to grow and evolve as you work to build the ideal solution. Paying attention to feedback from internal and external sources is essential to remaining on top of your goals. If you can’t change, you run the risk of losing the faith of your customers and the vision that drove your product in the first place. These best practices explicate the role that product management plays within the organization, the key values that you want to emphasize:
Product Management is a Balancing ActAt the very core of product management is the need to balance a wide array of factors, both within and beyond your control. While your target market might shift beneath your feet, if you have a vision, a strategy, and a measurable idea of what you’re looking to achieve, you’re in a prime position to develop and grow solutions that make an impact and carry you forward.
Product Engineering for a Remote-First WorldTransitioning from a single product company to a platform company is a time-tested path to growth for a small SaaS business. Building a platform, though, takes engineering bandwidth, and that doesn’t come cheap if you’re only targeting employees who live within 20 miles of a home office in a US city. The global shift to remote work was seismic, but it created new opportunities for businesses looking to scale a team and a platform. If everyone is in the same virtual place, no one is left out of decisions and progress, so the old-world inefficiencies of integrating remote teams disappear. As Ryan Breen laid out in his presentation, all it takes to activate this model is thoughtfully embracing a fully remote workforce.
Key CommitmentsProduct and engineering must commit to making this relationship work. Product needs engineering to build solutions on time and on budget, and engineering needs product to give them the requirements and time to do so. This all requires a well-defined relationship from sales to product management to engineering. Sales hears what the customer base needs. Product filters these needs into a roadmap that engineering delivers.
The Commitment of ProductAt its core, the commitment to product ties back to the idea of a central roadmap so everyone understands the future of the products they’re building, marketing, selling, and supporting. There are four key features of a working roadmap that Ryan highlights, each of which makes it easier for a business to communicate across teams, and demonstrate value to customers:
- One that customers want: While this may seem the most obvious, it’s easy to forget that the way you design, promote, and deploy your products should be in line with the needs and wants that your customers share.
- One that is actionable: Scope creep is always a risk, especially with distributed teams redefining the rhythms by which we all work. Your roadmap should be one that allows you to move forward and achieve goals on a weekly basis. You can’t afford to spin your wheels.
- One your whole business is aligned with: The rest of the business needs to buy into the roadmap. They need to commit to this roadmap as the best possible balance of context vs core.
- One that allows you to defend your focus: There’s always another customer need or new idea to chase down, but product needs to provide air cover so engineering can focus. Building a roadmap that communicates both process and outcome makes it easier for other teams to trust in product strategy and accept delays having their specific needs met.
The Commitment of EngineeringHoming in on engineering, it’s important for those building a business’ platform to understand what other teams need from them, and how they can best empower the organization as a whole. This commitment is best summed up in four tenets, provided by Ryan Breen:
- Build for agility and quality
- Define projects and goals up front
- Work as unified, global teams
- Finish on time
Why Remote-First?A globally unified development team is more cost-effective, of course. Done right, it can also be more productive, more predictable, and more reliable. Historically, communication was the main limiter on building remote teams. Almost all businesses had one center of gravity at a headquarters near a major city, and new employees added in new locales were excluded from much of the day-to-day planning and hallway conversations that are the lifeblood of effective teams. For most organizations, the only way to activate remote teams was to give them their own geographic silos and minimize the need for constant (minute to minute and hour to hour) communication between geographies. This typically meant dividing up different teams to own different products and features, leading to some or all of these problems:
- Knowledge of a product was siloed in a given geography. Need help supporting a customer when a team is asleep? You have to wait a few hours or wake someone up.
- Siloed products lead to differences in development standards and methodologies. If teams are building things their own way in their own technology stacks for months or years at a time, it’s much more difficult to move people from one product to another and have them contribute quickly. Varying approaches to development also lead to a jarring customer experience where it’s clear that different parts of a platform came from different teams.
- Teams were stranded working on the products they owned. Products mature to the point where they don’t need work in a given week or month, so what do you do with those teams? In this model, It’s hard to reallocate people from one product to another, given knowledge siloing and schisms in development approaches, so the natural tendency is to justify make-work on a given product even if it’s not the best use of time for a business.
- Most insidiously, teams didn’t trust each other. Human psychology is prone to an in-group / out-group bias, so it’s all too easy to view your team in your city as the productive one and to look down on products and teams that live elsewhere. It’s a rare organization that hasn’t expressed some form of cross-geography bias: “Oh, this is one of those products from a remote team. It won’t be as good.”