The essence of Convictional’s approach to product management can be summarized in two sentences from our CEO Roger Kirkness: “The purpose of product management is to define, assess, achieve, sustain, and deepen product/market fit. There is one output, it’s all that matters, and it’s how PMing is measured: product/market fit.”
Every hour of every day in product management drives towards deepening our product/market fit within our ideal customer profile. It requires a nuanced understanding of the customer and all of the risk/reward trade-offs involved in building a product that fulfills their most important needs.
There has been much written about whether a product manager (PM) is the CEO of the product or whether they are not. The reality is that this point does not matter — regardless of how much formal or informal power a PM holds, their only goal is to achieve PMF.
In this post, I’ll share the core philosophies, principles, and processes that define how we manage products at Convictional. You’ll understand how we operate, how we make decisions, how we engage with engineering, and more.
“The purpose of product management is to define, assess, achieve, sustain, and deepen product/market fit. There is one output, it’s all that matters, and it’s how PMing is measured: product/market fit.” - Roger Kirkness
Our core PM principles
Product management involves a high velocity of decisions. The majority of decisions are two-way doors (reversible) which lend themselves to quick decisions and execution speed. A small subset of decisions are one-way (irreversible) that can change the trajectory of the product or company.
A superior approach to making a large amount of decisions is to codify principles that can guide you towards the desired end-state of the product. Given that Convictional’s company-wide reading list features Principles by Ray Dalio, it's no surprise that product managers at Convictional also have a shortlist of principles that guide their decision-making:
- The easier you make it to trade, the more trade will happen.
Every single affordance (a thing that affords a user value) should be reduced to its essence. We want to minimize the amount of work (in the form of effort, time, thinking) and maximize the amount of value someone receives. The more we do that, the more usage we will have. - Aim to change as little of people’s habits as possible.
We want people to continue to be able to use their existing tools, while benefiting from the things we can do to fully eliminate work they had to do manually prior. If something can be done by a user’s existing system, we should try to enable it to continue to happen there. - It is better to automate something than to provide a great UX.
Often people are inclined to make the experience of using something better, which is great. We should only do that in cases where we have thoroughly explored the alternative of fully automating it and concluded that’s not possible. Full automation means full self driving, no steering wheel, configuration of notifications only (no real work). - Always build towards the long-term solution.
There are only two options to commit to when deciding on whether to resolve a customer job-to-be-done: either do not attempt to resolve the need, or fully solve the problem. Short-term solutions incur more maintenance cost and customer frustration than the interim benefits they provide.
Shipping with speed and relevance
The fastest path to learning is to get the MVP in front of customers (“shipping”). Customer usage is the greatest signal to confirm whether your product is solving the intended need. And paradoxically, the need for speed doesn’t go away as the team scales. The Product team at Convictional focuses on shipping velocity now more than ever.
In the early days of building Convictional, we held less certainty about the pathway to PMF. We had to be incredibly deliberate about the bets that we placed in terms of features to build and which customers to build for given that the team was small and resources were bounded. As the team scales and more resources are added, we increase our capacity to take on these bets. But the process of confirming whether those bets are successful doesn’t change — customers still need to interact with the product and confirm that they are achieving success or resolving pain points. Adding to the team makes us faster, not slower.
From Lachy Groom, the first PM at Stripe: “You should be iterating often. If you’re building a product, you’re designing the API well before it’s built. You should run those API docs by your reference customers. Talk to customers constantly. Know what would cause churn and what would make them more excited.”
The path is to talk to customers and iterate on the feedback.
How we build empathy for our customers
Our north star is product/market fit with our ideal customer profile. This means that deeply understanding that customer profile and empathizing with their needs becomes paramount.
Any product build effort should be driven by empathy towards the customer. Two of the most common pathways to deepening customer empathy are through speaking with the end users of the product and also learning how Convictional fits into our customer’s broader strategic initiatives. Another pathway is to spend time in customer support, seeing the day-to-day problems and questions that surface from users trying to meet their needs.
The idea of PM being rooted in customer empathy is not just a Convictional idea. Fahd Ananta described customer empathy as the most important trait to have in a product management role.
“Some of the best PMs Shopify hired came from the customer support team. They see how the customers think about the product and understand what they want.”
Fahd shared with me that Shopify’s product culture held the idea that “alignment is the most important thing”. One pathway to alignment is to foster a high degree of ownership across the organization — the customer’s pain points become pain points that the entire company rallies behind to solve. This theme of ownership transcends functions like Product or Engineering and ties a common thread between them.
“The more that people feel involved in solving the problem, feeling ownership over the company and the problem, the more they’ll act like owners.”
The idea of customer empathy applies to any member of Convictional, not just the Product team. But ultimately PMs are the ones that must make the judgment calls on the pathway to meeting the customer's needs.
“Some of the best PMs Shopify hired came from the customer support team. They see how the customers think about the product and understand what they want.” - Fahd Ananta
Our product development approach
Since product teams learn fastest through shipping, Convictional takes a high-velocity approach to getting work in our customer’s hands.
The two tensions to hold are whether we have a tight enough understanding of the customer’s need and how quickly we can solve the smallest version of that need. The MVP we build is intended to meet that need through the smallest amount of complexity and effort. From there, customer usage provides information that helps us inform where to invest our effort and identifies gaps that we may have missed in the first build effort.
The process of shipping & learning is laid out in Elon Musk’s universal engineering process:
- Make sure the requirements aren't dumb. If true:
- Remove all the requirements you can remove. If you aren't adding things back in later, it wasn't enough. If true:
- Optimize everything you can about the key outcome. If true:
- Accelerate the input process that gets value to the theoretical maximum (e.g. the production process). If true:
- Automate whatever is left.
This framework balances the tension between wanting to build the theoretical maximum of the product whilst recognizing that the fastest path to achieving it is through faster customer learning. This same tension is what a PM balances when building products day-by-day that ultimately roll up into the long-term product strategy.
The actual product development process at Convictional now looks like this:
- The Product team synthesizes context across customer feedback, usage data, and the broader industry. Product bridges into other functions like Success, Sales, Marketing, and Support to gather customer context.
- Hypotheses are created on the pathway to deeper PMF. These ideas are floated by customers qualitatively (and tested quantitatively when possible).
- User stories are drafted which form the foundation for requirements docs (specs). Broader-level context is added to requirements docs to root the user stories in terms of the customers, their businesses, and where Convictional intends to add value.
- Product works with Engineering to break down these user stories into engineering-relevant pieces of work. Convictional uses a process of “shaping” inspired from Basecamp’s Shape Up methodology with a set cadence for shaping, building, and reflecting before restarting the cycle.
- Product work is shipped (be that an MVP or a v2 of a product incorporating feedback) and our customers are enabled on how to best use it to achieve their goals.
- We learn from the feedback during the reflection stage and inform the next cycle with that information.
The result is that Product spends their time gathering all context and information relating to customer needs, Engineering builds towards those needs, and both teams root the entirety of their workflows in what will be most impactful for our customers.
But as the last point in the framework indicates, there is a difference between shipping a lightweight MVP and a more powerful second version of a feature. We make that decision using our concept of ‘squared away’.
Squared away: solving the Job-To-Be-Done (JTBD)
Products or features are only deemed successful when they fully solve our customer’s pain point. Drilled down, the purpose of a product is to solve the customer's job-to-be-done — the need they have that remains painful if left unsolved. This pain point is why the customer partnered with you or bought your company’s solution.
Measures of completion are born from the customer’s JTBD, not the level of functionality in the product itself. Which means that at any given time, there are two decisions: whether or not to build a product that fully satisfies a JTBD, or to not build towards it at all.
Once it’s been decided to satisfy the JTBD, there are four dimensions that a PM can choose to focus on: reliability, simplicity, power, and features. The reality is that you can’t focus on them all at once and some pairings can become mutually exclusive, namely reliability<>features and simplicity<>power. Those four dimensions begin to form two squares, the outer square being the full extent of the customer JTBD, and the inner square being the functionality of the product itself.
The goal is to make effective choices (and tradeoffs) on how to expand the inner square in a way that creates customer value and without significantly trading off on a particular dimension. New features come at the expense of reliability, powerful functionality often at the expense of simplicity. The journey to a product that solves the JTBD will involve tradeoffs on each dimension but must culminate in a finished product that satisfies the customers’ desires across all four. That’s when the JTBD has been solved.
Learning into PM
PM is fundamentally an apprenticeship model. PM requires judgment and a deep understanding of both the company and the customer base.
The process of learning into PM feels akin to reading Robert Greene’s book Mastery. There is a lofty goal to achieve, a mentor that holds the knowledge of how to achieve it, and then a multitude of repetitions to hone the ability to make good judgements.
When I first transitioned into PM from Customer Success, I spent countless hours learning from Roger. We dug into the history of Convictional, what succeeded and failed with our first customers, tag-teamed customer discovery interviews, diagnosed failure points in how our internal teams were communicating, and worked through new product specs together.
.jpg)
The process of learning from Roger gave me insight into the intangibles that PM has come to be known for. Of all the recommended reading on PM, there are two sources that stand the test of time: the prescient Twitter threads of Shreyas Doshi and the writings of Brandon Chu in Black Box of PM. I’d add a personal recommendation for John Cutler’s The Beautiful Mess essays too.
Our plan is for future PMs at Convictional to go through that same apprenticeship process of learning through shipping themselves, iterating quickly, and figuring out their unique style in how they deepen our PMF.
If you align with how we think and our approach to product management, join us! We’re actively hiring across all of our teams, including Product.
To Launch & Scale Your Digital Marketplace
Chat with us to learn more
