David Wiener is Chief Product Officer at Voicera, which leverages AI technology to harness the power of voice in the workplace. To read part one of his three-part series, Building a Startup, click here.
Once you have established a high-level perspective on building your startup’s tech stack, you then need to decide exactly what you want to accomplish. If you are going for a simple product use case, you might have a lot of different options. But if you are looking to support a sophisticated set of product use cases, you need to think a bit more deeply about what success looks like.
For Voicera, we started with a smaller set of use cases that we wanted to deliver. But as we started mapping them out, the list grew. Since we didn’t want to spend tons of engineering cycles building every use case ourselves, we had to prioritize their implementation.
We ended up with a dozen core product use cases that we found critical to our business:
Onboarding: We wanted our new-user onboarding experience to be well integrated into the product and evolve as the product and marketing messaging developed.
Live Chat: We knew that customers would run into problems as we built the product, so we wanted to deliver a world-class customer experience. This involved searching for a solution that would allow us to speak to our customers and prospects in real time and quickly assign the appropriate team member.
Support Desk: One of the benefits of startups is being able to build systems for capturing and cataloguing customer data from the start. So while this use case started out as wanting to track customer support issues and follow up with customers when their issues had been resolved or feature requests had been built, it grew into wanting to capture every bit of information a customer had ever given us.
We wanted to pull up a single customer record and know everything about that user—their name, title, job function, location, every product feature they had or had not used, the performance of our product, how heavy a user they were, how influential they were in exposing others to our product, their payment plan, and more. Oh—and we wanted it all in one place.
Help Center: We have a philosophy that we should never answer the same question twice. Our help center would be our central repository for customers and our support team to access information about product features, FAQs, help guides, and best practices.
Behavioral Emails: Personalization and behavioral emails were a crucial part of the strategy. We wanted to be able to nudge users down our conversion funnel, send relevant product announcements to the right people, and personalize emails based on job function, title, organization, and product usage.
Business Intelligence (BI): The philosophy behind our desire for a BI platform was to instrument everything and shift metrics as the business evolved. We wanted to warehouse all of our user data somewhere, join it with backend systems data to write queries against it, and quickly share dashboards across the team. We wanted the data to be friendly enough that a business person with basic pivot-table knowledge could use it, but powerful enough that a developer could create custom join tables and write database queries against it.
In-App Feature Announcements/Tutorials: We wanted to announce new features to users when they were in the app, increasing their understanding of usage and benefits at the right moment.
CRM: We needed a CRM that consumed user data, and would be explicitly used by the sales teams. They needed similar information as the customer service team and also an efficient way to dive deeper.
Payments: As we would eventually take payments, integrating a payments vendor seemed like the right thing to do at the outset. This would allow us to track trial length and smoothly roll users into paid plans.
Conversion Tracking: We wanted to track how our marketing converted to leads and users. Surprisingly, this is not an easy problem to solve. We wanted to understand which pieces of content and which marketing campaigns were productive for us. We wanted to see this data pass into our user onboarding system and downstream to all of the consuming systems.
Personalization: We wanted our users to feel like they had a relationship with us from day one. To do this, we wanted to enrich their profiles using third-party context data.
Fast Debugging: When a user had a problem, we wanted to be able to jump right on the issue without having to ask basic debugging questions. We wanted to be able to debug based on operating system and browser versions, replay browser session information, track console errors, see where customers were getting frustrated, and jump into live screen-sharing if needed.
Our 12 core product use cases did not all jump out at us initially. The main use case we started with was new user onboarding. Using artificial intelligence in a meeting is a new concept, and we needed to explain a lot about Voicera to new users. In the spirit of starting with something simple and iterating over time, we implemented three drastically different versions of onboarding, each time refining it based on user feedback before moving on to other use cases. The simplicity of starting with something manageable and evolving it really helped us zero in on what is most impactful to our users.
In the same vein, having a help center was not something that we required early on. We intentionally deprioritized it, but as we grew, allowing users to learn about the product and read tutorials became more important. Similarly, CRM was also not an initial requirement, but as our partnership and sales teams evolved, this quickly became a necessity.
Prioritization and refinement of your product use cases guard against getting spread too thin. Once your use cases are set, it’s time to implement!