Matthew on Warpcast

Content pfp

0 reply

0 recast

0 reaction

Matthew pfp

Anyone want to compare notes on how they write product specs? Feel free to reply with critiques / feedback, or share one of yours. As a solo dev I could yolo features without writing specs, but I find that the deliverable makes me more methodical and thoughtful. So I'm curious how / if others write theirs. https://eventsxyz.notion.site/Recurring-Events-Public-6215091ea67b44508c691af87fc1faa6?pvs=4

11 replies

5 recasts

22 reactions

Rch pfp

one thing that I find helpful is documenting the metrics you would be tracking. That helps in surfacing the instrumentation you should have in place. Also, felt you might find this useful https://www.lennysnewsletter.com/p/my-favorite-templates-issue-37

0 reply

0 recast

0 reaction

chief chups pfp

@chiefchups.eth

I’ve been using this template for a few years now. works nicely https://docs.google.com/document/d/12-EzRTjsnB1ouZ8EypBr9KLshrTKOk8-DUDNASkkdSc/edit

0 reply

0 recast

0 reaction

Shashank pfp

this template from lenny is very similar what we used at airbnb https://docs.google.com/document/d/1541V32QgSwyCFWxtiMIThn-6n-2s7fVWztEWVa970uo/

0 reply

0 recast

0 reaction

will pfp

i like the why / what / how structure. short & simple i think the most important part is just to drill as hard as you can into the "why {does this matter / is this worth doing}?" in your posted example, why are recurring events important? (e.g. hosts and attendees both desire / value longer term relationships.) why is events the right team/product to include this? (e.g. is it complementary to ad hoc events and requested by existing [power] users? relevant to your mission? strategy?) what is painful about the current experience? potentially even who, if anyone, has given you feedback specifically on this (for motivation, grounding, & follow up). the section on channel calendars is interesting but i would move it to the "how" (at least the details of it, could still be worth mentioning in why briefly)

2 replies

0 recast

2 reactions

carter pfp

i take a really similar approach to this doc but break it down a bit more into sections. for me the goal of the doc is three parts: 1. understand all assumptions without this communication really suffers and half the time sharing the doc is eaten up by doing this anyway 2. align on the (ideal) end goal much easier to talk about how to get to a shared goal than discuss many approaches to a near term goal. also for solo work it really helps long term focus 3. figure out how to get there explore the different spaces and write down all the approaches so I can remember why later and also discover assumptions so most docs end up taking the form like 1. problem 2. goal 3. current state 4. solution 5. post-solution 6. alternatives

1 reply

0 recast

1 reaction

Angel - Not A Bot pfp

Angel - Not A Bot

my spec template is three sections: Problem - a bunch of questions that prompt thinking about why we're building this, who we're building for, and how it moves the needle on our north star. Solution - Generalized description of how we can solve the problem. What can we test with minimal eng resources? Product - Mock ups, analytics events, price segmentation, all the implementation details p.s. what do you use to make these diagrams?

1 reply

0 recast

0 reaction

binocularsXL🚀 pfp

binocularsXL🚀

Hey Matthew Would you consider allowing users to be able to edit the event name just up until they want to finalize the creation?

1 reply

0 recast

0 reaction

vrypan |--o--| pfp

I spent five years writing specs. An important aspect of specs is context. It's often thought that a spec stands on its own, but in reality a spec is written for a specific audience (in my case it was our dev team). Once you know your audience, you have to get in their shoes and think what they consider default and where they will need clarifications as they start working. A good spec answers all the questions in advance, and lives out the defaults that don't need clarification (but may be a good idea to mention them). If you have well defined defaults, your life gets much easier. Naming is also an important part, the better things are named and defined before you start, the easier it is to write a spec.

1 reply

0 recast

1 reaction

law pfp

I thought it was about “writing” in general I was getting ready to read and have my opinion too lmfaooo

0 reply

0 recast

0 reaction

S.G Baby pfp

What’s the duplicate part for?

0 reply

0 recast

0 reaction

⋆♱ 9̷0̷†մղ ♱⋆ pfp

⋆♱ 9̷0̷†մղ ♱⋆

Why add a possible add-ons sections; i feel that shouldn’t be there and if you want to communicate that, you can do it through here

0 reply

0 recast

0 reaction