[HN Gopher] Building Products at Stripe
___________________________________________________________________
Building Products at Stripe
Author : herbertl
Score : 126 points
Date : 2021-05-18 14:25 UTC (8 hours ago)
(HTM) web link (newsletter.bringthedonuts.com)
(TXT) w3m dump (newsletter.bringthedonuts.com)
| peter_l_downs wrote:
| In my experience, Stripe is full of very smart, interesting
| people, but most of what's described here is an aspirational view
| of how the current executives think product _should_ work at
| Stripe. That 's OK, in some sense any view of the "self" is going
| to be aspirational, but it seems naive/koolaidy to believe that
| all of the following things can be true at the same time (these
| are all quotes from the article):
|
| - "it's an incredibly deep-thinking culture. It's a written
| culture really focused on getting to the right answer"
|
| - "The company is especially dedicated to moving very, very
| fast."
|
| - "deep thinking and speed are combined with a substantial amount
| of user focus and user empathy."
|
| - "We talk a lot about building multi-decade abstractions."
|
| - "Quick-thinking, quick-acting people do really well here."
|
| - "It's craftsmanship and a huge amount of dedication to getting
| all of the details right."
|
| - "There is just the feeling that it should all be exceptional.
| We should push for an extreme quality bar on all of the fronts."
|
| This seems like a pretty standard fluff piece that's aimed at
| recruiting PMs who want to identify as near-super-human talent.
| Stripe is a fantastic place to work but this kind of
| communication does them and their employees a disservice -- that
| said I'm not a recruiter and can't say what kind of tactics work
| best for finding PMs.
| msiliski wrote:
| Michael from Stripe here (the interviewee).
|
| While it's true we are always hiring, this wasn't meant to be a
| recruiting piece--it's a personal interview Ken (the author)
| asked me to do based on demand from his readers.
|
| It's fair to say this is how we want product building to work,
| and we certainly don't always live up to it. But I do think
| it's broadly reflective of the operating model our product
| managers, engineers, etc. aspire to and what we hold ourselves
| accountable to. Do we fall short of our own aspirations
| regularly? Absolutely.
| peter_l_downs wrote:
| The interview is certainly useful in that it reflects
| Stripe's aspirations as a product team. I would have found
| this interview much more interesting if you had been able to
| go into detail about the reality of working on a product team
| where you're holding yourselves to a set of mutually
| incompatible constraints -- what tradeoffs you tend to make,
| how you think about making them, what are the common failure
| and success modes. Maybe a good follow-up post; consider this
| a single reader's suggestion, not a demand :)
| vbtemp wrote:
| Am I alone here in feeling like that all sounds incredibly
| exhausting and like a pretty draining place to work, and not-
| so-subtly seeks to attract workaholics?
|
| It's like there's lip-service to things that we as software
| engineers enjoy about our profession (eg craftsmanship, deep
| thinking, high-quality work), but it comes across as just
| throat clearing before hammering in "moving very, very fast". I
| read that constant repetition of "moving fast" as "you will
| always have an endless backlog of work that you will
| nonetheless have to endlessly crank through with all your
| energy, and our hiring/retention policy only selects for that"
| czbond wrote:
| I can see how many of those items fit - at times I thought they
| were literally describing me.
|
| Founder that got into products at first using CompSci skills -
| but finally realized it is the problem solving through business
| that kept me engaged and pulling me back.
|
| The 30 year vision helps stretch the mind from what is around
| us (pulling from what is know) to creating an ideal solution
| and working backwards.
| hitekker wrote:
| I think little of zeal outside of close-knit groups. It takes
| too much effort, it's easily misdirected, and it can be faked.
| At scale, it incurs a deficit between input and output,
| willpower and reality, and eventually achieves its close cousin
| and exact opposite, cynicism. In the world after zeal, trying
| becomes pretending, enthusiasm becomes opportunism; anything
| done the cause becomes suspect in the eyes of those who had to
| suffer the cause.
|
| The inability to control zeal seems common to communist
| republics[1], "rocket-ship" startups, and other half-baked
| endeavors that don't know how to get work done without
| demanding religious fervor/perfection from their unfortunate
| subordinates.
|
| [1] https://en.wikipedia.org/wiki/New_Soviet_man ->
| https://en.wikipedia.org/wiki/Homo_Sovieticus
| captainoats wrote:
| I hear this "fast is slow, slow is fast" type culture
| perpetuated a lot in product. What they're describing is lots
| of experience, practice and general intelligence. Always feels
| pretty masturbatory when you write it out.
| e_commerce wrote:
| Stripe needs to reduce fees
| dbbk wrote:
| You can negotiate the fees
| [deleted]
| natdempk wrote:
| One thing that stood out to me was the aspect of having a strong
| culture of writing. Could anyone talk about how Stripe's culture
| of writing works a bit more? How does this manifest in things
| like product decisions/direction, setting technical direction,
| designing systems/APIs, etc?
| FionnMc wrote:
| I often hear about this concept of deep thinking and deep drive
| into user stories. My experience sadly is much of the work in
| companies is dominated by smaller tasks. I'd love to know how
| stripe handles this balance between big feature developments and
| smaller issues.
| Scoundreller wrote:
| Here I thought Stripe was getting into the lumber and nails
| business. Can we get a [verb] tag? /s
| nocommandline wrote:
| 1) >>> Stripe runs on written long-form documents in a way that I
| haven't seen before. <<<
|
| 2) >>> The product shaping document will come at it from the
| perspective of a user. <<<
|
| When you combine bullets 1 & 2, it makes for very good
| documentation. It was one of the things I loved about Stripe when
| I first tried to use them (plus the simplicity of the product at
| that time).
|
| However, my latest experience with Stripe is that their
| documentation is becoming similar to Google documentation i.e.
| multiple pieces of documentation describing the same thing but
| the different documentation is not consistent especially when
| they are using the same scenario. For example, you might see 2
| different documents (from Stripe) that talk about embedding an
| online payment form and those 2 would have the same example but
| one would give the impression that you only need to deal with X
| attributes while the other one will show you that you actually
| need Y attributes. Some of the attributes could also be named
| differently (the name has probably changed and one document has
| not been updated while the other has or was written after the
| attribute was changed).
| sciprojguy wrote:
| This is similar to my experience. My company <redacted> is
| doing a stripe integration and I wasted a week playing with the
| multiple different sample apps that were provided "as is" and
| only made significant progress by ignoring them and building my
| prototype up section by section from the "getting started"
| documentation.
| [deleted]
| jordan-stripe wrote:
| Hi! I'm Jordan, a manager on the Documentation team at Stripe.
| Thank you (and thank you to others on thread) for sharing this
| valuable feedback. It would be great to get more details about
| your experience. This kind of feedback allows us to make
| specific changes that will help you (and likely many other
| users) in the near term. Drop me a line at jordan@stripe.com
| and I'd be more than happy to chat.
___________________________________________________________________
(page generated 2021-05-18 23:02 UTC)