February 2022 Summaries

Getting a pricing model right is crucial for any SaaS company, but finding one that works can be challenging. A startup's goals evolve over time, and the pricing model should adapt accordingly. The text describes three iterations of a pricing model for incident management tool incident.io. Initially, they used best guess-based pricing to attract customers and gather feedback. Next, they moved to vision-based pricing based on organization size but found it didn't resonate with all customers. Finally, they implemented value-based pricing focused on active incident responders, which has shown positive early indications from customers. Key takeaways include the importance of changing pricing models when necessary, focusing on the mechanism rather than just the numbers, ensuring revenue targets are met, understanding product value, and seeking customer feedback.

Incident.io, a small startup with big ambitions, has developed an outline of how they kick off projects. The process begins by choosing a scout who guides initial conversations about the project and prepares for a successful kick-off. Next, a prior art document is created to collect different approaches taken by other products, which helps avoid re-inventing the wheel and inspires discussion. Then, the team works out in detail what their new product will look like, considering factors such as customer experience, technical feasibility, and MVP scope. After that, they consult with customers to gather feedback on the proposed feature, which is then used to refine the project's direction. Finally, the team starts building while remaining open to learning more about the problem domain and adjusting their approach accordingly.

Incident severity levels are crucial for measuring the impact of an incident and facilitating communication and categorization within an organization. When designing these levels, it is essential to have a consistent set across the entire organization, provide clear guidance on how to set them, and choose the right number of levels (typically 3-5). The recommended severity levels are Low, Medium, High, and Critical, with human words being preferred over code words for clarity. These levels should be customized according to an organization's specific needs and business impact.

An early-stage B2B SaaS company has been tracking its adoption rate and receiving positive results from customer feedback channels. The company uses four main channels for feedback, ranked by contextualization and detail: customer calls, Slack Connect channels, Slack Community, and Intercom. They also use various tools such as Grain, Slack, ProductBoard, Linear, and Metabase to manage their feedback process. Some strategies that have worked well for the company include digging into the "why" behind feature requests, using Slack-Productboard integration, sharing new feature proposals, keeping customer success and engineering close, and consciously separating customer vs prospect feedback. The company is looking forward to implementing more efficient processes such as finding a Customer Success CRM, scaling customer calls, consistently gathering NPS data, and gathering feedback post-trial.

The three pillars of great incident response include clarity, transparency, and calm. Clarity involves having clear roles and responsibilities within the team, focusing on the problem at hand, and using actions to avoid duplication of effort. Transparency requires defaulting to public information sharing, fostering a blameless culture where mistakes are learning opportunities, and intentionally sharing relevant context with stakeholders. Calm is achieved through trust among team members, having good tools for gathering and verifying information, ensuring adequate energy levels, and gaining experience in handling incidents.

Clear writing plays an essential role in product development, as it helps create a user-friendly experience and ensures effective communication between users and the product. Engineers at startups often need to assume the role of copywriters when developing new features. Establishing a consistent tone of voice early on is crucial for maintaining a recognizable product identity across multiple platforms. Good writing should be concise, friendly, and easily understandable by non-native English speakers or users with reading difficulties. Avoiding jargon and keeping sentences short can enhance the user experience. Additionally, incorporating a conversational tone of voice can make using the product more enjoyable.

Incident.io has a transparent engineering interview process, with four main stages: Initial Call, Hiring Manager Interview, Coding Challenge, and System Design. The company iterates on its interviews based on feedback from candidates and the team's experience. In the Initial Call, candidates discuss expectations, product, team, culture, and technology stack. The Hiring Manager Interview is a "get to know you" conversation focused on problem-solving approaches and career experiences. The Coding Challenge tests coding skills in a self-contained utility with a test suite and two missing features. The System Design interview involves designing a system for a potential product, considering failure cases and resilience. Lastly, the Culture interview is an opportunity to discuss values, motivation, feedback, and conflict resolution.

This guide provides a sensible approach to incident management for early-stage startups, focusing on what is important and what can be deferred until later. It covers defining an incident threshold, setting simple severities, deciding where incidents will be logged, creating a fresh space to coordinate during an incident, being clear about roles, keeping customers informed, and avoiding lengthy post-mortems. The guide also mentions the benefits of using incident.io for efficient setup and management of incidents in small organizations.