In August 2019, MedStack introduced a pivotal product after years of learning from our customers about their needs when it comes to quickly bringing digital health solutions to market.
MedStack Control marked the introduction of our first self-service platform, offering turnkey resources for running Docker applications in compliant environments.
MedStack is composed of technical and non-technical internal stakeholders. We rely heavily on our team’s range of knowledge and expertise when discussing product features, capabilities, and boundary conditions.
The ways we align our organization, while speaking to the various depths of the product, has been turned into a company-wide product process we call “themes.”
This process has allowed us to quickly evolve our business model so our users can continue running their applications reliably and affordably at scale, during a time when digital health solutions are in extremely high demand.
Here’s how we do it.
Running themes, not sprints
Many product teams run Agile frameworks to ensure they are continuously delivering value to their users by means of Scrum or Kanban. By the book, Agile is an incredibly effective way of doing this.
In reality, it can be quite difficult to achieve this imagined level of throughput from all teams if prioritization is not done correctly.
In response to feeling the challenges of building product under such frameworks, we sought a way that allows us to maintain whole organization alignment with the flexibility to change priorities on a dime, all the while still executing our executive strategies.
We call our solution product “themes.”
Our flavour of themes was inspired by Jason Fried, founder of Basecamp, where each product initiative is tackled by a small team often composed of 1-2 developers, a product designer, and a product manager. Every product initiative is broken down into a 2, 4, or 6-week project.
The team is also given the autonomy to execute their theme tasks with the intention of maximizing a state of flow day-to-day by limiting ceremonies in favour of continuous feedback and improvement. Here is an example of what their themes look like.
Not to be underestimated, it takes a special culture cultivated by the entire team (stemming from the founders) to have the level of trust and transparency required to make continuous feedback and improvement actually work in practice.
Since employing themes, we’ve been able to align our entire organization around supporting product initiatives from their gestation through to launch.
Creating and executing a theme
The creation and execution of a theme can be broken down into five (5) phases:
- Talking to customers to understand the problem
- Establishing the requirements
- Briefing the team and trimming the scope
- Facilitating the product development and product marketing streams
- Measuring the results and doing it again
Talking to customers to understand the problem
In product management 101, we learn about listening to our users. If you ever need to turn back to first principles (which is a great thing to do), start with this.
After all, we have two ears and one mouth, so we are better off listening to what our customers want rather than speaking for them.
In organizations without product managers, the problems users are up against are commonly heard (1) during sales or discovery calls, and (2) when providing support.
It is often a user’s objections or impediments that resonate with us. The root of this objection or impediment is indeed the problem, but coming to understand the problem and its relative impact to your product requires patience and objectivity.
Since Sales and Support are often two separate functions of the business, user problems are heard in isolation and departamental biases are formed.
In addition to this, Sales and Support teams are often speaking to different stakeholders; the needs of the buyer and the user personas interacting with the product can be very different.
The conflict between buyer vs user needs, communication silos, and executing company strategy can impose significant challenges on prioritization and maintaining a bias for action. The result is often building products that are:
- Rich in half-baked features, fragmented, and incomplete, or;
- Technically sound, limited in capabilities, and unappealing in the market.
In either case, both outcomes usually have a poor user experience simply because the user is not understood along their journey from a time before they were your customers through after their churn.
Understanding the problem starts with the product manager listening to the many business functions, their biases, and most importantly, the user along their entire lifecycle before and after your product.
In order to truly understand the problem in most cases, product managers must spend time with (1) potential users, (2) current users, and (3) churned users (if you are lucky to have this opportunity).
In order to maximize the likelihood of speaking to (3), you will want to invest significant time and energy in supporting users from the very beginning of their lifecycle.
At MedStack, we have done this by ingraining the following operations into our product management day-to-day:
- Conduct demos and field sales calls to learn about what the market needs and what is available today.
- Provide solutions and prioritize support inquiries to gauge the size and frequency of product shortcomings, as well as to feel the user’s problem.
- Contribute to and own the product knowledge base to become an expert in the product and its boundary conditions.
- Contribute to content and digital marketing to understand what is compelling across different segments and personas.
- Perform 1:1 onboarding calls with new users to understand what they will need to be successful.
- Interview existing customers on their experience with something new being introduced to the product.
- Perform exit interviews/off-ramping calls to understand product shortcomings.
Paul Graham said to do things that don’t scale when exploring new ideas. This operational process certainly does not scale well for product teams, but it has been essential to understanding our users throughout their lifecycle with our product, thus highlighting both the things to celebrate and the things to improve.
As problems are understood, a regular dialogue is taking place with the relevant internal teams to get a better sense of the pervasiveness, size, and anticipated ROI of what might become your next product initiative.
We use Michael Ho’s priority mapping framework to understand our next product initiative. It allows us to make progress on company strategy while selectively choosing the user problems we need to solve.
Priority mapping is also a great way of validating the company strategy against real user problems because it forces you to grow the business in a way that always comes back to asking who the users are, what they’re trying to achieve with your product, and how they achieve these results with and without your product.
Establishing the requirements
Requirements start with the minimum acceptable solution (acceptance criteria) to solve the users’ problem, then grow to accommodate the relevant needs of the different business functions.
A product manager needs to seed these requirements having a high-level understanding of technical (engineering), operational (sales and marketing), and strategic (leadership) constraints.
Building a familiarity with these functions of the business is imperative to intuitively drafting requirements.
The result is a list of requirements that cover both the “happy” and “sad” paths of a user journey where their problem is being solved, detailing what each business function needs and may expect in the solution created by engineering.
During the requirement gathering phase, the product team regularly touches base with each relevant internal stakeholder as well as our users to ensure we are thinking about the problem at a low-enough level to understand the expectations and intended outcomes, cross-departmentally.
At MedStack, we use a combination of the (1) jobs to be done and (2) user story frameworks to achieve this specification. The resulting document is a product proposal that encompasses these specifications.
It’s important to note that the resulting document is extremely readable by the whole organization. It contains no jargon, complex terminology, nor solutions.
One of my favourite quotes about product management comes from the book, Trillion Dollar Coach, a biography on Bill Campbell, as it points at the importance of avoiding solutioning.
“Bill liked to tell a story about when he was at Intuit and they started getting into banking products. They hired some product managers with banking experience. One day, Bill was in a meeting with one of those product managers who presented his engineers with a list of features he wanted them to build. Bill told the poor product manager, “If you ever tell an engineer at Intuit which features you want, I’m going to throw you out on the street. You tell them what problem the consumer has. You give them context on who the consumer is, then let them figure out the features. They will provide you with a far better solution than you’ll ever get by telling them what to build.”
Briefing the team and trimming the scope
The briefing kicks off the official start of a theme for the rest of the team. It is among the favourite days for a product manager because it is likely the first time all the relevant business functions are rallying around this initiative in a single room.
Here is what the agenda for a meeting like this looks like.
- (1) Silent read of theme briefing (5-15 minutes)
Give the team some time to silently read through the theme brief. Comments in the document are welcome as we will come back to them after everyone has gone through their silent read. We embrace this method as inspired by the best tech companies.
It’s an extremely effective way to address questions that would otherwise arise if we were first reviewing the document together. This helps focus the conversation on the complete requirements presented and helps everyone to holistically collect their thoughts around the theme.
- (2) Discuss the document and comments from top to bottom (1-2 hours)
After the silent read, discuss the document from top to bottom, reviewing the scope of the requirements, how they flow from one to the other, and amend them to correct misinformed assumptions or account for new or changed business requirements that become more evident once the spec has been gathered.
The intended outcome of the two items above is a list of polished requirements that capture the ideal state of implementing the theme, having validated and corrected assumptions from the various internal stakeholders.
- (3) Building the solution (1-3 hours)
This pertains to the product development team who will be building this solution. Together, they ruthlessly trim scope to solve the problem within the timeframe sensibly allotted for the initiative.
Although this is a costly meeting to run, the time spent planning will be more than amply paid back during the execution phase of the theme.
Facilitating the product development and product marketing streams
At the beginning of the following day, the product manager informs the organization of the amendments made during the scope trimming and evaluates the priority of the trimmed initiatives to be considered for a future theme.
The development team executes spikes, agrees upon schema, designs for expected I/Os at the lowest shared level, and executes a planned development strategy to bring the theme to life.
To facilitate the product development stream, we create a temporary channel in Slack called, for example, #theme-012-backups, where all communication takes place between product, design, and engineering.
Temporary channels are better for this than say, the #engineering or #product channels as it allows all parties to collaborate in a laser focused discussion.
To facilitate the product marketing stream, we create a temporary channel in Slack that matches the product development theme, where we would call it, #playbook-012-backups.
The playbook informs the Sales, Marketing, and Support teams on how to sell, how to promote, and how to support the release of the theme, respectively.
It is the distilled list of action items and information that enables the business and customer success functions to seamlessly adopt the impending changes as they make their way into the product.
Measuring the results and doing it again
During the first phase where we invest in understanding the problem, we in parallel draft how we might measure the success of a solution we implement.
Brainstorming success metrics during the earliest phase helps to keep product teams honest and focus on measuring the hypothesized results of a solution, rather than focusing on the details of the solution itself.
Once the theme has been integrated into the product, we use the temporary product development channel (#theme-012-backups) to discuss and track the KPIs that measure the success of the solution we implemented during the theme.
Feedback on the solution’s performance can be empirical, anecdotal, or sentimental and often comes from all sides of the business. We tend to think of themes as experiments, so we are able to iterate on the solution if we feel it does not indeed solve the problem on the first iteration.
Subsequent iterations within the same theme are done if permitted in the maximum tolerated time allotted to solving the problem.
By holding ourselves to this soft rule, we avert the sunken cost fallacy to bring a solution to market all the while hitting the key beats of the larger company strategy.
