Jean-Michel Lemieux on Shipping, Hiring and Product Alignment

Jean-Michel Lemieux contrasts Shopify’s emphasis on quality with Atlassian’s emphasis on speed and argues that teams should build a movement as well as a product. He joins Harry Stebbings to discuss shipping, hiring, alignment and AI-assisted development.

Lemieux traces his interest in computers to combining music, art and mathematics at school. He used a computer and keyboard to produce music for a school performance, then followed a counselor’s advice into computer science. For him the computer was a creative tool, not an end in itself.

His advice to people entering work is to build on what they are good at. At Atlassian and Shopify, he says he learned the importance of founders playing a long game and investing in marketing and community, even when the immediate focus of engineers is building.

He recalls Atlassian building a community around how teams work and Shopify nurturing an entrepreneurship movement. In his account these were deliberate efforts to bring people together around a shared goal, rather than relying only on product features.

Lemieux says both companies had strong founder partnerships, but their working cultures differed: in his experience Atlassian often shipped quickly while Shopify spent more time on a smaller number of things and could stop work over quality. These are his observations from particular periods, not fixed descriptions of either company.

He contrasts Atlassian’s business mechanics with Shopify’s focus on a product customers love and recommend. Both needed to monetize, he says, but used different levers. His account reflects his former leadership roles at both organizations.

Stebbings argues an early company can win by narrowing its ideal customer profile. Lemieux agrees that young teams have more ideas than they can execute and benefit from doing a few things very well before expanding.

Rather than choose between speed and quality in the abstract, Lemieux suggests deciding repeatedly which work needs exceptional polish and which can be shipped faster. The choice depends on what customers notice and what foundations are necessary; his current small company is an experiment in that balance.

His team limits its regular design discussion to an hour a week and focuses on what is shipping now and what must be prepared for the next month. A longer-term vision remains important, but he says excessive discussion of distant work can crowd out present execution.

He measures progress by looking at what teams ship and its quality, including pull requests, rather than treating lines of code as a target. A single line can be consequential; the useful signal is a sustained cadence of meaningful output.

Lemieux says he has retired from rigid software processes in his current work. His concern is not all planning but what he calls time-horizon friction: people planning distant projects repeatedly interrupt builders, leaving more meetings about work than time to do it.

His experiment is to align on a three-year direction, discuss the next month’s work and hold a short weekly meeting on blockers. He believes shipping can reduce risk by generating feedback, while acknowledging that the right amount of planning depends on context.

He thinks large organizations also need alignment and believes Shopify is pursuing related changes, though he speaks from outside the company at the time. He argues schooling can train people to complete assignments alone, whereas building software often requires collaboration, prototypes and feedback.

To understand a team’s performance, he asks leaders what they shipped and which results were good or great. He wants people throughout an organization to develop a shared quality bar rather than judge success by adherence to a process.

He challenges the advice to hire great people and simply get out of their way. Autonomy works better after people align on goals and standards, he says; otherwise excellent hires may move in incompatible directions.

For a new executive, he proposes “pair programming” on leadership: agree on a few priorities, work through decisions together and also ask the leader to identify additional opportunities. He recalls reviewing a new engineering leader’s React Native work and writing together to learn how each other thought.

He uses frequent small exchanges to align on decisions without turning everything into a meeting. Stebbings pushes back, preferring trusted employees not to send him daily updates; the two disagree about how much contact is useful.

Lemieux borrows a decision-tree framework: root decisions are consequential and hard to reverse, trunk decisions may benefit from discussion, and leaf decisions can usually be made independently. He suggests teams explicitly agree which decisions need alignment.

His hiring process begins with a “snowboard test”: an open question about a candidate’s ideal role to understand what naturally motivates them. He wants to know whether the work the company needs is the work the person actually wants to do.

Next he asks the person to teach him about an area they care about, probing how deeply they understand its layers. Finally he discusses the job and asks about the hardest thing they have built, using the answer to explore judgment, quality and how they sought help.

He generally values motivation, skill and capacity to learn over identical industry experience, while acknowledging that certain domains benefit from direct experience. His assessment is a hiring philosophy, not proof that experience is unimportant.

Common mistakes include failing to notice a candidate does not really want the job and assessing only one layer of a complex role. He wants interviewers to know where a person is strong and where they may need help, rather than searching for a supposedly perfect candidate.

His own poor hires often came when he rushed and skipped parts of his process. When a manager leaves, he now tries to buy time: gather the team, clarify what customers still need and offer support, instead of promising an immediate replacement.

He also maintains a continuous network of people he would like to work with, aiming to meet someone interesting each week. When a role opens, prior relationships give him more context and reduce pressure to start the search from zero.

Lemieux is enthusiastic about AI coding tools, comparing them with the computer-assisted music he made as a student. He says a copilot writes roughly 80% of his code in his own current workflow, while he handles architecture; this is a personal estimate, not a measured industry productivity rate.

He predicts AI will help smaller teams and redistribute technical talent toward underserved areas such as healthcare, education, agriculture and energy. He expects the range of problems to grow, but does not establish future employment outcomes.

Stebbings worries that incumbents have unprecedented cash, data and speed. Lemieux sees opportunities to build better infrastructure, such as government and healthcare systems, although he acknowledges that building foundational platforms is difficult and may take a long time.

Asked why strong teams become average, he recommends a “pace bunny”: regularly compare notes with peers about what they ship, incidents and operating practices. External reference points can reveal both common problems and places where a team can improve.

Returning to zero-to-one work has been lonely at times, he says. His wife has been a source of support through highs and lows. He also enjoys trying new tools and learning directly from their builders.

He praises Equals as a customer because it connects spreadsheet work with shared data, and explicitly says he has no investment in it. Stebbings raises questions about price, customer acquisition and crowded positioning; Lemieux says liking a product does not establish that it is a good investment.

In quick fire, he says CEOs often underestimate the daily work of finding customers and building community. He warns against hiring too quickly and recommends spending time on customer support when starting a product leadership role, as he did at Shopify.

He describes tension among design, product and engineering, and sometimes sales. For one year he says he led Shopify’s sales team to help align which customers the product was ready to serve with the company’s sales priorities.

His team found similarities between small merchants and very high-volume brands with relatively simple catalogs. Rather than pursue every complex customer immediately, he says Shopify focused on customers with shared product needs while improving capacity for larger volumes. This is his recollection of the strategy.

Once product and sales agreed on the customers they wanted, Lemieux says the sales team could move quickly toward those accounts and the product team could focus its roadmap. The conversation closes with thanks.