[wpietri]

Are you excited to be writing lots of detailed specs? Especially in a startup, that seems terrible to me. When I've done startups, one of the best things for me about them was close collaboration with the product/design side of the house. Detailed specs would have slowed that down significantly for us.

[adjkant]

I've noticed that people can conflate "detailed spec" with "terribly meticulous process". Close collaboration with design/product doesn't mean that writing things down isn't useful, and can come in handy specifically:

1. When capturing complex logic areas, especially if related to any areas that are related to money or legal considerations

2. When onboarding new people on any side who need to learn about or get context on a product (product, design, eng)

3. When you revisit a V2 3 months later and forgotten what decisions you made or why you made them

Lots of detailed specs to me sounds like a fast velocity of products and totally compatible with startups. That said, you also added the word "lots" that OP didn't use. It could just mean two or three!

[neltnerb]

I would go further even and say that for any team that doesn't all do just one thing, developing the spec is half the work.

Once all the interconnections are figured out and the mechanical engineers know what needs to hold what shape at what temperature and pressure, and the metallurgists know what chemicals will be touching the metal, and the power connectors to sensors are all numbered so you know how many you need and where they'll go, and the communications lines with what format and inputs/outputs they'll talk to at what voltage... to me a spec is the document that tells everyone where their little part needs to fit.

You have to do that downstream and collect it back upstream for larger projects, since the person doing it never has enough expertise. And then the spec negotiation between teams that don't really necessarily know what constraints each other has which need to be resolved so that people know what to design.

It's frustrating but actually writing down a detailed spec really does enable a lot of other stuff to happen. I'm sometimes blocked as an individual because of a team that's in my path but which isn't really in my field. Say, they do optics and I design the optical sensor so I need to know the optical power to expect but they have to do simulations and get information from the chemists and semiconductor test engineers first. I need a spec for what they want -- I need to know how low the light level is, how much noise there is, and lots of other little details too.

I don't know if that qualifies as "terribly meticulous" but in my experience skipping the spec step often means wasting an incredible amount of time solving the wrong problem.

[adjkant]

Yep fully agree! I wanted to highlight some areas that devs may immediately "get" but "developing the spec is half the work" really should be shouted from the mountaintops.

[nojvek]

Amazing. Love PMs who can dive into details and clarify edge cases.

That’s half the battle of writing code.

At our startup, the philosophy is to “first write code without writing code”.

This gives clarity of problem and proposed solution to weed out edge cases, before going too deep into implementation phase.