Polygonal Product Management™

Everyone knows to ship small and iterate. Hopefully you’re getting to an MVP as quickly as possible so you can learn as quickly as possible. And hopefully you’re not stopping there; going beyond an MVP to ultimately develop a great feature.

Iterate through MVP to greatness

But do you keep going on a single feature until it’s awesome before moving on to another feature? If so, you’re doing depth over breadth. This is great, and nothing to be ashamed of. But there are other options. You can also do breadth over depth and ship a bunch of MVPs, never really improving any single feature until you’re “done”. Maybe then you go back and improve a bunch of the features, and slowly raise the quality of the entire produce until it’s great. Again, this is a valid approach.

Depth over Breadth vs Breadth over Depth

But let me introduce another approach. The depth triangle.

Depth triangle

Here, you constantly develop new features and get them to the coveted MVP state, then pick up a new feature, ship an MVP. But after a while, go back and improve one of your older features. There can be several months lag before you truly polish a feature, but you do eventually get there, all while continually increasing breadth.

Product Discovery


Product Discovery is a term for working very quickly to discover a product or feature as you work on it, with feedback from users, in an area of significant uncertainty. The process described here works best when innovating in a somewhat well-known space. e.g. adding a new feature into an existing product.

When doing product discovery, don’t start with a plan for the entire sprint. Plan enough for the first iteration with a goal of finishing within 1-2 days. Then ask “what’s the next most important thing”, and work on that for an iteration. Ideally, do 5 iterations a week, with each one needing a little planning.

Start with some brainstorming on what could be done without regard to time (call this “Think Big”), then narrow down to what the most important thing is to deliver in 24-48 hours (call this “Think Small”). Then work on that, as a team, and deliver the first version within 1-2 days. Then see how it feels, and decide what the next most important thing to work on is, and iterate. Then iterate again. And again. At some point, have external users take a look for validation, and add some metrics for tracking success. By the time you’re done, you’ve got a beautiful, polished, and valuable project finished and validated.

The thinking big part is great to get people out of local optima and think about the big picture. Context swap everything you can on the subject in a short period of time. Go crazy with ideas. Then narrow that down to the core of the feature. What’s the one thing you can deliver that would satisfy the goal without all the fluff. Sometimes it’s surprising what turns out to be the main point and what we can get away without.

Example Week

Example Week



1 week sprints. Planning is 2 hours. Standups are daily and walk-the-board style rather than yesterday/today/blockers style.


PM and Eng Management get together at the end of the previous sprint to gain a better understanding of priorities so we can go into the sprint better prepared for planning with the team.


Retrospective is about meta — it’s not a status update on the last day or even the last week of work. It’s about what went well, what didn’t, and most importantly what would we do differently or what can we learn from it. Sometimes we can’t do anything more than surface a problem with no immediate solution. Retrospective should aim to be only 15-20 minutes with a hard-stop at 25 minutes. If something really deserves more time, perhaps it should be a separate meeting (with less/more/different people).

Prioritize and allocate

Decide on project/product/feature to work on (and who will work on it, if there’s more than one project ongoing, which shouldn’t happen very often).

Think big and think small

  • Expand feature - what can it be.
  • Shrink feature to something achievable in 24-48 hours - cut scope to the minimum to make it functional and shippable.
  • Define metrics to watch and define what success looks like.

I’ve heard that Google and maybe Apple do some kind of expand and contract phases, although I think one of them expands on a Friday and then contracts on a Monday. Anyway, it’s a powerful tool.


  1. Deliver iteration of the product/feature.
  2. Test with ourselves, coworkers, and users.
  3. Decide on and implement the most important improvements, whether they are functional, UI, or UX.
  4. Repeat.

The first iteration should take 24-48 hours, with the rest taking 4-8 hours, for a total of 5 iterations in a week. 7 iterations if you’re awesome.


  1. Deploy
  2. Measure success of product/feature with real customers (private beta, public beta, or GA)

Sometimes you can expand from internal alpha to private beta to public beta within a single sprint. Sometimes you can only get to one stage within a week and you increase scope in subsequent sprints. The important thing is to always aim for learning as quickly as possible. If internal users are still providing surprising feedback, and you’re learning from it, then that’s still valuable.

Sprint Philosophy

  • Premature optimization is the root of all evil
    • Seriously, read Lean Startup. Putting any time in something that is later going to be thrown away because it turned out to be the wrong thing is the worst efficiency possible. Do just enough to validate. Focus on your biggest risks first.
  • How does this benefit the developer (user/customer)?
    • This doesn’t mean the customer is always right, or that we’re not allowed to think for ourselves, but that we should always make sure the user is represented in the discussion. Don’t talk (only) about internal or engineering benefits. Make sure it’s going to be of benefit to the end-developer.
  • Always work on what’s most important right now
    • Sometimes breadth-first beats depth-first. If customers are having a horrible experience with documentation, how can we say another iteration of notifications is more important?
    • But timing matters too — if we just finished an iteration on something, there’s value in leveraging that momentum (reducing context switch, etc.).
    • But don’t forget that we learn more about a feature as it’s being used, so letting something be out in customers’ hands for a while might result in better insights into the next most important thing rather than just theories in our heads.
  • Work on one project at a time
    • It’s important for the whole team to work on the same project. It doesn’t have to be the same feature, but it should be the same space. It sucks if one developer is working on something completely unrelated, or design is working on the next project ahead of engineering.
  • Work on one project a week
    • It’s important to plan a single project for an entire (week) sprint. Finishing one project on Wednesday then starting a new one on Thursday rarely works, at least for product discovery work.
  • Always finish sprints cleanly.
    • Don’t let WIP spill over the weekend. Saying “I’ll finish it on Saturday” rarely works, and even if it does, it can’t be peer reviewed and shipped until Monday and then it’s impacting the next sprint. This isn’t about working overtime. It’s more important to ask what scope can be cut so you still deliver on time. If you really want to code on your weekends, pick up something new for fun.
  • Collaborate and communicate
    • Communicate throughout the day, not just at standup.
    • Eliminate blockers — Tight loop always wins. When a decision needs to be made, get the relevant people together and make the decision - 5 minutes or less.
    • Roles (PM, Designer, Engineer) should only be used to resolve tie-breakers. Everyone’s opinions should be valued regardless of origin. The entire team owns the solution. Nothing is more powerful than ownership.
  • Iterations FTW, Refactors FTW
    • Everything is an experiment. Start with a hypothesis.
    • Iteration is better than perfection - But actually iterate; iterating once is called doing a half-assed job. It’s OK to ship things that aren’t perfect.
    • It doesn’t count until it ships. (Ship in this case can mean the point where you can learn something.)
    • Don’t be afraid to take time to refactor.
  • Design is about understanding and solving problems, not just the looks
    • Designers work in code whenever possible, using Sketch/Photoshop when necessary.

Product Management for Startups

The most important thing for a product manager, is to be right. If you’re not right over 80% of the time, you’re just not cutting it. If you use all the right tools, but are still wrong, it doesn’t matter. And if you’re right and don’t use any tools, it doesn’t matter. But of course, using the right tools can help you be right more often, so let’s take a look at some of the tools that help you do that.

Getting Started

There’s always the classic SWOT analysis (Strengths, Weaknesses, Opportunities, Threats). It’s a simple tool that helps you get the lay of the land, so to speak. In a startup, you likely already know the answers, but sometimes writing things down helps crystalize things, or at least communicate things to other people that haven’t thought about it as much. I don’t use it much personally, but if you’re new to this, it’s a great place to start.

SWOT en.svg
SWOT en“ by Xhienne - SWOT pt.svg. Licensed under CC BY-SA 2.5 via Wikimedia Commons.


In an early stage startup, you’ve got to have a great vision for where you’re going (and a mission and shared values), but that doesn’t mean having a rigid 3 year roadmap. Your world changes too quickly and you’re learning new things about your business every day. But that also doesn’t mean you don’t need planning at all. You have to make sure you’re doing the most valuable work at any given time. Just focus on one quarter at a time. Specifically, answer the question, what would be stupid for us not to do in the next 90 days? Make sure to include your customers’ perspective in the planning, but don’t forget to ask engineering as well. They’re close to the problem and have great ideas that customers may never ask for, yet truly need.

Put all the ideas up on a board, with a small description for each. Pandora used a single presentation slide for each idea. Marty Cagan pitches a Product Opportunity Assessment with 10 key questions. Lately I just use a Trello card with 4 simple questions (and links to any relevant links to prior art, proof of concepts, or supporting documents):

  • What’s the problem being solved?
  • Why is now the time to solve it?
  • Roughly how much effort is involved and from which teams?
  • How is this going to help us achieved our business objectives?

Then filter the ideas down to the most important big ideas. Get the exec team together and vote on them. Remember, focus means saying “no” to a thousand good ideas.

Ship Small and Iterate

When working on a project, don’t get caught up in defining everything up front, even if you’re only looking at 3 months or less. The sooner you get things out of your head and into customers hands, the faster you’ll learn. I’m a big fan of product discovery popularized by The Lean Startup movement. Ship small and iterate.

Aligned Empowerment

Your team will grow too large to do the above planning all together. And really, at some point your company will be capable of delivering more than one person can organize. You’ll need to hire more product managers, and divide up the product space. Resist the temptation to keep central control over everything. Empowering small teams, each with a product manager, to make decisions about what they work on is incredibly powerful. The people closest to the work should be trusted to know what to tackle next. And teams work best when they’ve been working together for a while so durable feature teams are your friend. But don’t let it devolve into anarchy. Your teams need to be aligned to common goals. A compelling and well-articulated vision is key here.


Eventually, as your startup grows, you’re going to need a roadmap. Especially for enterprise customers, they’re not just buying your product, they’re buying the future version of you. But rather than submit to their demands, create an agile roadmap that understands that you can only see clearly for so far and your vision gets blurry past 6 months.

Start with your product vision, brainstorm ideas, separate the big “boulders” from the “pebbles”, then categories the boulders by level of commitment. Don’t be too concerned about making sure everything is committed with a timeline. Some projects can be worth committing to even if you don’t have a clear idea how long they’ll take to finish. Then of course there’s those projects you can’t completely commit to, but will likely deliver at some point. And then there’s the big visionary stuff; the ideas that might not show up in a year, or even five years, but these aspirational goals help define you. Lastly, it’s just as important to write down what you won’t do. Once you’ve got all that, you can cluster things down into a sharable roadmap.

Product Planning Process

Product Planning Categorized Boulders

Product Planning Milestones

Also consider the “problem roadmap“ rather than the “product roadmap”.

Lean canvas

Yeah, you can try out the Lean Canvas, especially if you’re still pre-funding. I haven’t used it myself, and I find the format rather dry, but it seems to be gathering momentum.


Well, that’s all I’ve got time to cover today, and I feel like I’ve left out a lot of great pieces like balancing customer requests, metric-moving improvements, and visionary features. And the Think Big, Think Small exercise. Maybe I’ll cover those another day.