'Shape Up' Ryan Singer's advice to YC companies

Ryan Singer gave us the honor to meet with a small group of Y Combinator founders a few weeks ago in Paris. We learned so much from him that we felt compelled to share the insights more broadly. 

At Lago, our product shipping approach is heavily influenced by Ryan's Shape Up methodology, which we have adopted to enable us to deliver fast and efficiently (cf How we ship fast). Hence, the opportunity to meet him was even more thrilling for us.

First, who’s Ryan Singer? 

We like to call him the “god” of product management. Ryan Singer is a product designer and the head of Product Strategy at Basecamp, a project management and team collaboration software company. 

He is well-known for his work on user interface design, product development, and user experience.

Singer has been instrumental in shaping the design and functionality of Basecamp's software products for 17 years. 

He has also authored a book called "Shape Up: Stop Running in Circles and Ship Work that Matters," which offers insights and strategies for effective product development. We took a lot of inspiration from this book to define our product methodology at Lago (Described in the How we ship fast post). 

One of the eternal debates within product teams revolves around the question of how to prioritize the product roadmap. Ryan offered us five key learnings in this regard, which we found incredibly valuable.

Learning 1: Start by selling “what’s on the truck” 

Ryan starts emphasizing on the fact that every company should learn how to sell what’s “already on the truck”, that is to say “existing features”. 

If you’re unable to sell anything at the beginning, this means you have “no truck” and you should figure out what to build first. 

If you’re able to sell what’s on your truck, customers that are requesting new features without paying for them can actually indicate a lack of perceived value in the product. This can be addressed by better targeting (Are we chasing the right customers?) and better product marketing (Do people understand what this product can bring to them?). 

It's essential to avoid constantly building custom solutions for individual customers and instead focus on developing a product that customers genuinely love and find easy to use.

Additionally, when iterating on the customer journey, it's valuable to work on both "Big Hire" (the decision to hire a product, e.g., buy a new coffee machine) and the "Little Hire" (the decision to use the product daily, e.g., use the coffee machine). Understanding these decisions will provide insights into identifying “jobs customers want to be done.” at each step of the process.

Learning 2: Recognize “Bad money” from “Good Money” 

Another useful framework to prioritize a roadmap is “Bad versus Good Money”.

"Good money" are revenue streams that lets you build your product while staying free and flexible in your choices to best meet the common need of your customers. "Bad money" are revenue streams that lock you up in specific choices for specific customers, forces you to develop custom features out of your product vision and brings noise in your growth.

“Good money” buys you freedom, “bad money” makes you hell in the future.

For instance, in Lago’s case, we chose not to become a payment processor. 

We handle the subscription management, usage metering and billing aspects and decided to connect with a variety of Payment Processors (any payment processor our users might want to use: Adyen, GoCardLess, Stripe Payments, etc), rather than owning the payment processing. We often share revenue with payment processors (they would typically retrocede a portion of their revenue to Lago, as we bring new users to them). We see this as “good money” as we can focus on our core offering (billing), address our users’ needs (connecting billing to payment processors) and create a new revenue stream.

“Bad money” would have been to decide to become a payment processor today. We would have, in theory, captured more revenue (payment processing is lucrative), however, that would have defocused us from our core offering (billing) and might have triggered a lot of operational constraints we were not eager to invest in at the moment. Also, it would have forced our users to churn from their existing payment processor, which wasn’t our initial vision of building an “agnostic billing layer”. 

A good rule of thumb is also the “one versus all”: asking yourself if there is one (if any) person willing to buy a specific feature or more than five people in the lead pool? 

According to Ryan, “2% of your customers are often the loudest about the things they don't have, the lack of that feature makes the other pay.” 

To summarize, a good sign of “product market fit” is actually when a team is comfortable with “saying no” to a customer’s request. 

Learning 3: Framing, Shaping, Delivery

To prioritize features, Ryan recommends starting with “framing sessions”. The framing phase is the exploratory research phase that allows teams to understand the high-level user problems that will be candidates for the roadmap (which will be further developed during the scoping phase, where we delve into the details).

A framing document should also showcase the problem we want to tackle, the impact of this problem and how it can increase the main KPI we’re looking into.

A typical product development workflow would look like this: 

1. Framing → Defining the user problem. Is it a good problem to work on? (led by a co-founder, a Chief People Officer or Product leader)
2. Shaping → Shaping the work and the impact of the work, with a technical, design and a customer point of view. Solutions should be defined and tested, ideally by Engineers as they are the best suited to have in mind the impact of building the solution
3. Delivery → Building the solutions led by Product Managers, Product Designers, and/or Engineers

Feature prioritization should impact the main KPI we’re looking into but in the meantime, not denature the product. 

Learning 4:  Betting tables are more relevant for bootstrapped companies 

"Betting tables" refer to a visual representation of the work to be done within a development cycle. They are used as a tool for prioritization and decision-making..

The purpose of the betting table is to allocate resources and make decisions about what work should be taken on within a given development cycle, which is called a "six-week cycle" in Shape Up. By visually representing the available work and the capacity of the teams, the betting table helps in deciding which projects or features should be worked on and which ones should be skipped or postponed.

Ryan admits that betting tables are more relevant for bootstrapped companies. Indeed, VC-backed ventures might have to answer to investors’ imperatives, such as increasing revenue faster for instance. In that case, related initiatives will de facto be prioritized by the founders. 

Also, among the companies that use the “Shape Up” methodology, only around 10% use betting tables, according to Ryan. 

Learning 5: To shape the product, you need an architect 

Product designers generally fall into two categories: the artist or the architect. The “artist profile” is like an interior designer. The “architect profile” will build the foundations of your product, and work with the interactions and the user flows. 

Although you always need interior design work in the product delivery, you’ll need your product designer to have or acquire architect skills to accurately design experiences. 

It’s a distinction to keep in mind when you’re hiring your first product designer in the early days. 

‍

Thanks again Ryan, Jean-Edern (Palette) for the organization, Martin (Carbonfact), Clément and the one and only Mike (Lago) for sharing your notes, and Le Wagon for hosting!

‍

‍

Bonus: recommended reads/listens

Selling what’s on your truck by Gary Turner, founder of Xero

The innovator’s solution by Clayton Christensen & Michael Raynor

Jobs to be done by Bob Moesta