Principles of Product Development

How to build and scale a great product culture at your organization

The Principles

Here are the principles that I shared with my teams and stakeholders. Many of these ideas are inspired by Marty Cagan’s blog and books, Intercom’s blog on Product, and ideas from the Lean Startup. I hope you find this valuable in spreading the product culture in your organization. Leave a comment if you’d like to discuss these ideas further, I’d love to hear what you think!

• We solve problems: We measure success based on problems solved. We work on products, not projects. Projects are all about output (did we ship the feature?) and Product is all about the outcome (did we solve the problem?).
• We are iterative: When new information surfaces, we are not afraid to change our plans. Our assumptions may be wrong, requirements could evolve, timelines could change. Updating our plans and communicating them is key. “We don’t start with quality, we end up with it.” — Vince Huang.
• We like to ship value fast and frequently so that we deliver end-user value quickly, and get real user feedback. We endeavor to be creative and find the minimum viable product to ship. If we were building a car, we’d be happy to ship without the air-conditioning, however, we would NOT ship without the wheels.
• We ship incrementally: We prefer to ship in small incremental pieces, over one large release. Smaller releases are more efficient, predictable, and result in a higher quality of delivery.
• We tackle risks early: New problems, technologies, and solutions introduce risk. Our goal is to identify and tackle these risks early through prototype testing before we build the final product. We test our ideas through prototypes, surveys, false-door tests, A/B tests, and any other means of rapid testing.
• We work collaboratively, side-by-side: We need to bring Product, Design, Stakeholders, and Engineering to the table at the same time, not one after the other.
  “In strong teams, product, design, and engineering work side by side, in a give‐and‐take way, to come up with technology‐powered solutions that our customers love and that work for our business.” — excerpt from Marty Cagan, INSPIRED.
• We validate our ideas early and frequently: Validate your solutions early and often. Most products fail because customer validation happens way too late, or after launch.
• We are focused: High utilization is not the same as high performance. We believe that fewer and focused projects will get done faster and better.
• We stay the course: There are two fundamental truths about Product Development that require us to stay the course in order to solve customer problems. The first truth is that at least half of our ideas are just not going to work. The second truth is that it takes several iterations to get the solution that solves the customer problem and delivers business value. We call that time-to-money.

Communicating the process

My goal was to get the product team and business teams to understand and internalize these principles. This meant that communicating this process effectively was super important. From past experience, I knew that it would not be enough to publish an internal document and expect the teams to read and understand. So I decided to use an active approach to drive engagement and discussion. I scheduled a meeting to discuss these principles and requested the product managers to bring examples from Springboard, or past project experiences to enrich the discussion. What followed was a great conversation and alignment within the product team. As a next step, we did the same with stakeholders outside the product team. We used examples of projects that we’d collaborated on to discuss whether we had or failed to apply some of these principles. This was a crucial step in beginning to build a great product culture in our organization.

Let’s talk about why

I lead the product team at Springboard, an online learning bootcamp based out of the Silicon Valley. As our business grew, we hired a number of business and operations team leaders across the organization. Many of the new hires had not worked with product teams before, which made quarterly planning and cross-team collaboration a seriously (un)fun activity, LOL.

One of the important problems that every product leader needs to solve is scaling the product culture at their organization. A common joke in Product circles is that everybody defines the role of a product manager differently. Imagine what it is like for outside stakeholders and business team leaders. In order to collaborate across functions effectively, product managers have to explain how they work and how to work effectively with them.

I started to define and scale the product culture at our organization. The obvious answer to the scaling problem was introducing new processes. I don’t like processes that fail to explain why they exist. I believe that principles should precede processes. Starting with principles ensures that processes make sense when they are introduced.