People First

I’ve interviewed many people for GitLab, and one question I often get is about what it’s like being remote. GitLab is famous for being all remote, and possibly the largest all-remote company. But when I’m asked that question, I like to go in a different direction. GitLab isn’t just about being all-remote, or remote-first, it’s about being people-first. We’re not all remote because of the cost of office space or the ability to hire the best talent all over the world, or any of the other great things about going remote. These are benefits, but they’re not the reasons. We’re all remote because we’re people first, and people live all over the world outside of major cities. Why should we make them move? Why ask people to spend hours commuting? But when you put people first, it’s more than just being remote.

I used to work at a place that was remote-friendly, eventually with 50% of the workforce being remote. It started out that we allowed people to work remotely, but only if they agreed to work on an SF schedule. We eventually relaxed that (as it’s a pretty ridiculous requirement), but only allowed individual engineers to work remotely. Eventually we let managers be remote, but still I’d hear people comment about how leaders can’t be remote. We had one person who lived in Seattle fly in every Monday and out every Thursday to accommodate our HQ-centric perspective. Eventually that faded, and we started hiring more leaders remotely. When one particular leader was hired, who had tons of experience working remotely, he presented a few tips for people to successfully work remotely. They included things like having a set schedule for yourself and making sure your team knew your schedule, and to let them know if you were going to deviate from it. Makes sense, right? If you have to be away, it’s harder for people to notice when you’re remote, so be proactive in your communication. When you start work in the morning, say hello in your team channel, if you step away, let people know, when you’re done for the day, say goodbye.

But GitLab takes a different approach. We explicitly say not to check in and check out of your team channel. We used to ask you to mention what you were working on every day, which had innocent intentions, but cut that part out of our handbook because it felt too big-brother-esque or butts-in-seats minded. Your schedule is nobody else’s business. Your results are what matters. If you need to go to an appointment in the middle of the day, go. If you’ve got to pick up the kids from school, go. Heck, if you just need to take a nap, go for it. We have people all over the world, there should be no expectation of an immediate response anyway, so write your communication clearly and concisely and prepare for an asynchronous response.

For me, I love that when my kids come home from school (back when they actually went to school), and they’re excited to talk to me about something, they can interrupt me. It only takes 15 minutes, and then I’m back to work, but those 15 minutes mean the world to them, and to me. If I waited 2 hours until my workday was done, the excitement would be gone. It would be even worse if I had to wait an extra hour to commute home. When my kids were little, there was a period of time when I’d make it home from work just in time to put them to bed. I’d miss dinner, I’d miss bath time; I’d get maybe 15 minutes total with them during weekdays. Now I have breakfast and dinner with my family every day. I even occasionally have a lunch date with my wife! That wouldn’t be possible without being remote, but it also requires putting people (and their families) first.

Being all remote is just one consequence of a deeper commitment to putting people first. As another example, GitLab, like many companies had an all-company call. But unlike many companies, the main focus wasn’t on one-way presentations of company or department announcements to the rest of the company, the focus was on two-way communication about people, as individuals. This wasn’t a daily standup where people talk about that they did yesterday, what they’re doing today, and what blockers they have; it was a chance for people to talk about their personal life. A favorite topic was what you did the previous weekend, or what your plans were for the following weekend. As we grew, we couldn’t let people talk every single day, but we’d assign people to talk on certain days of the week, and eventually to a 2-week cycle. I’m an introvert and don’t generally like engaging in small talk, but I found myself really looking forward to these calls. In the in-between times, I’d take notes and prepare what I wanted to share with the team. And people didn’t just share warm-and-fluffy topics, some of the topics were deeply personal. People really opened up.

We also have an all-company summit (now called Contribute) every 9 to 12 months. Again, the focus wasn’t on getting work done, because we better be able to get work done remotely, but in connecting to each other in ways that take advantage of meeting in-person. We’d go ziplining in Mexico, or tour Santorini in Greece, or hike Table Mountain in South Africa. During one particular summit, I arrived and met up with the other GitLabbers, and gave one of them a hug. Then it really hit me how well we’re able to connect as people. Not only was this the first time I had met this person “in person”, but this was the first time we had even ever had a direct conversation. Our only interactions were during the company call, and yet we each felt like we knew each other really well because of how much we’d shared. And when GitLab grew too large to continue having both the department announcements and the personal calls? I feel like every other company I’ve been at would make the obvious choice, to drop the personal content and stick to the essential content. But that’s not what GitLab did. We cut the departmental content and kept the company calls about personal connection.

These are the main examples I bring up, but the reality is that there are a ton of decisions made every day where things could go one way or the other. And most companies sooner or later end up deciding to protect the bottom line, or whatever story they tell themselves to justify doing something that isn’t great for the employees. But GitLab has always chosen to make the hard, but right call to continue to put people first, and that makes all the difference.

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.