Tag: tech

Product Toolkit: Quick Proposal

Product Toolkit: Quick Proposal

(if you’re just looking for a link to the QP template, here it is!)

This post is the first in what I hope will be a recurring series where I share some of the tools that I use, and work with my team to develop, in our product practice. In this way I hope to show our work, make the role of the Product org more transparent and accessible, and maybe help folks find success in their professional life (or maybe personal life, who knows!)

You’ll hear a lot of opinions about the role of Product Managers. They’re probably all right in their own way. Realistically, different teams will leverage the title “Product Manager” in really different ways. Sometimes it’s predictable; Product at a seed stage startup is going to be incredibly in the weeds and will wear about thirty hats. Product at a big legacy company needs to think more about organizational topology and cross functional buy in.

This is even setting aside the great controversy of “Product Work,” as in, “We’re not even spending our time doing Product Work,” which is a whole different and interesting conversation.

I’ve settled on a position, as one must, in these matters. It’s my sense that the most important thing a good Product team does, is they work very hard to avoid building the wrong thing. There are a lot of tools and approaches, mindsets and strategies, but a good Product organization should mostly be focused on maximizing a firm’s opportunity to get it right, and the fastest and most effective route there is to minimize time spent building the wrong thing.

There’s a lot written about Product Discovery (there’s even some right on this blog!) – if you’re curious more generally about how to assess opportunities, talk to customers, and why it’s important, I recommend starting with the singular Teresa Torres and her excellent book, Continuous Discovery Habits.

Discovery within an organization, finding ways to gain a better understanding of what’s going on within your company, how to get things done, getting sufficient input from the right folks, is a key input to Not Building The Wrong Thing. The thing is, it can be quite a lot different from interviewing customers and reviewing AARRR funnel exercises.

For one thing, these people have a fundamentally different relationship with you than your customers do. Ideally, they have an actual relationship with you! You work together, you have shared interests and (hopefully!) are aligned on what it means to find success in the upcoming quarter, year, and so forth.

They’re also busy, and unlike your customers, there can be a lot at stake in their interactions with a product person, even one with great intentions, even one with whom they’re aligned. Seasoned professionals are also very aware of the challenge of building things within larger companies, and the amount of uncertainty and potential risk to their own careers, especially around taking big swings.

There is a pattern of behavior here that I have seen myself, and have heard discussed many times in product circles, where it feels like nothing can gain purchase on the actual backlog of real, living engineering and operational teams. It feels like you’re stuck in a cycle of meetings, discussing at a high level the trade offs, propriety, the sensibility of a given possible piece of work.

You’re stuck in Abstract Land and just want to clear the air, and get something moving.

(There’s a blog post here about, platform product teams serving the role of uncertainty sponges, maybe?)

It’s not that your partners and stakeholders are doing anything wrong, or malicious – in fact, like you, they’re behaving in accordance with their rational incentives. It can be challenging to get out of high level abstract space and down to decisions, in part because:

  • Folks don’t want to get it wrong: the fewer calls you make, the easier it is to avoid getting it wrong
  • The abstract space is easier to be misunderstood / misaligned: if you and your colleague are saying things that are sort of aligned, in the fuzzy abstract, that’s fine.
  • Folks don’t want to give direct feedback to a colleague. It’s much easier to correct a representative from a company you pay for a product from, than someone you might work with or need help from in the future.

One way to get out of this space is with a Quick Proposal. A Quick Proposal is a tool in the product toolkit that leverages one of the fundamental laws of the internet:

“The best way to get the right answer on the Internet is not to ask a question, it’s to post the wrong answer.”


Cunningham’s Law

A Quick Proposal is just that – a short written summary that offers your partners and stakeholders a chance to correct, update, and provide feedback on a document that takes a position, rather than staying in an abstract space.

Features of a good QP:

  • It is one page long, and dated
  • It is written in under 20 minutes
  • It is in a format that everyone at your firm can access and comment upon
  • It contains a brief round-up of what is known about the space under discussion
  • It links out to other existing documentation, research, data, etc.
  • It has a section called “Recommendation” which contains your best bet for the next action to be taken given the discovery and discussions that have occurred.

While a QP can help to spur action, it isn’t necessarily meant to be acted upon – it’s meant to:

  • Capture your best understanding of a situation in as specific terms as possible
  • Create at least one possible recommendation for next steps based on that understanding
  • Generate a target for stakeholder feedback that isn’t another person, but a document

The way to use a QP is to present it as a loosely held summary – not, “I believe this is what we should do next, what do you think?” but more, “We have a lot of threads here, so I’m taking a crack at getting everything together. Does this look right to you?”

I’d also recommend when requesting feedback that you ask specific, relevant people directly, you provide a date by which time you’d like to make a decision, and you extend the offer for feedback to anyone else they’d recommend as having a voice in the matter.

A QP sometimes ends up being developed into a go-to-backlog type document (a One Pager, a Product Brief, a Product Requirements Document) but it’s real capital-J Job is to get your group and project out of the strategic stratosphere of Abstract Land and down to tangible discussions of what to do, how to do it, and when it can be scheduled, or, in the pursuit of Not Doing The Wrong Thing, perhaps it is set aside for other, more appealing opportunities; that’s also a win!

Here’s a Google Doc Template if it’s helpful!

5 Arguments Against Salary Transparency

14348835516_1438e862d2_b

Or, SAO Thinks About Buffer, Part Two. Here’s Part One.

In chatting with folks about Buffer’s approach to salary (making not just the process of assigning a salary, but the final number for each employee) transparent both internally and externally, there have been some common arguments against it. I’d like to talk about them a little, and discuss my thinking about each.

You’ll recall from Part One that I think that the transparent salary system is a great one, though I would impress upon the skeptical reader that my primary philosophical approval is for the transparency of the process – the actual visible list of salaries at the end is, in my view, a pleasant side effect of a much bigger, and more important, piece. The process being transparent is really the lynch pin here, I reckon.

Here are some arguments I’ve heard against salary transparency, and my thoughts on them:

“I think salaries are a private and personal thing.”
I’d suggest that this is a cultural artifact that holds us back. Seeing how salaries are assigned takes something that is currently invisible, and makes it visible. The final numbers are much less important than the fact that the process that results in those numbers is visible and accountable – making the actual salaries visible is simply a check on that process, a verification that it works as intended and displayed. Invisible salaries (and salary assignation processes) open the door for unjust practices that have become endemic, and are likely often simply the result of unknowing implicit biases – women being paid less, minorities being paid less.

I think transparency around salary processes and final salaries may place some tension on our traditional ideas of what should be private, that is certainly true. But, I think that making them public and visible is much better for us, as workers and as a society that desires equity, in the long run.

“I trust our HR department to take care of that.”
That’s great! I also am lucky to work in a place where I truly believe that our HR department has the best interests of the employees in their hearts, and I trust them completely. That being said, I don’t have to trust anyone else I work with – because their work is visible and available and under review from the rest of the company. This black-box nature of salary assignation is not only bad for non-HR employees, it’s bad for folks in HR – it means that they can’t have open and frank conversations about issues that might concern them, it means they’re denied the usual diversity of perspective and insight from their comrades with particularly tricky issues.

As well, it’s worth noting that the Buffer system is entirely self-contained – the questions of salary exist entirely within a box of particular questions and qualifications. During interviews and salary discussions, it becomes much easier and less stressful for the HR staff – no more fuzzy edges or uncomfortable conversations. It’s all in the spreadsheet.

“This is a non-issue. If you’re happy with your own salary, then stay where you are. If you aren’t happy with your salary, then find a new job.”
This mistakes the final result for the process – the question isn’t about the particular salaries of employees, or my salary specifically, but rather visible assurance that everyone’s being compensated fairly. That’s it – whether or not I’m happy with what I’m paid has no impact here. In a more transparent system, I’d at least be able to ask questions about why I’m paid what I’m paid, and how to make moves in the right direction (“So, how can I move from Rookie to Journeyman?” etc).

“I have absolutely no interest in seeing salaries.”
I don’t think anyone’s suggesting that it would be mandatory reading – I’d be curious to know how many folks actually do review the pay sheet, internally, at Buffer.

“Public employers have had transparent salaries for a long time, and they’re famous for being inefficient and having stagnant promotion patterns.”
True as this may be, I think we can acknowledge that there is an essential and important distinction between government employees and folks working at cutting edge tech companies. New companies doing business in new ways bring all sorts of interesting iterations on longstanding traditions that can often bear excellent organizational returns – I’d argue that transparent salary assignation processes is a great example of this. Just because transparent salaries are a property of a class of organizations we do not want to emulate does not mean that it won’t really shine when we try it in a new class of organization. So, let’s do it!

What do you think? Do you have an argument against fully transparent salaries and salary assignation processes?