How do you define the requirements for your products?

Chris Rickard
7 replies
Hey team, I'm curious how everyone collects and refines the requirements and features for their products? When I started out (many years ago!) I would just "jump in", and work on the fun interesting features, and then other ideas would come along. Now I'm a little more strategic, and actually create users personas, user stories, and user journeys - to map out the types of potential customers, their problems, and how they would interact with the product. (I actually build Userdoc which I'm launching this week to help exactly with that). Love to hear how others manage this 🙂

Replies

André J
Start small, iterate. Planing is just guessing anyways. At best.
Chris Rickard
@sentry_co agree! Requirements are iterative, add more as you learn more - evolve, and keep them fluid.
Žiga Kerec
We launch with the minimal requirement we got by talking to our initial clients. Those could just be interviews or and early no-code prototype. Later we add features according to the usage or additional feedback from pir clients.
Žiga Kerec
@chrisrickard we hold a weekly meeting. Usually Monday midday. We take a bigger user story and break it down according to the task category (development, design, research). Single task usually shouldn’t take longer than a day.
Chris Rickard
@ziga_kerec Awesome, as a team how to you breakdown your tasks?
priyanka prasad
We would go about creating user personas & user stories once we have collected feature requests from our customers. We are Using ProductLogz for collecting feature requests/ suggestions and Jira for creating user stories. Userdoc definitely looks interesting and given the Ai, looks like it will reduce a lot of manual labour & time in creating user stories.
Chris Rickard
@priyanka_prasad5 Awesome Priyanka, I'm the first to say AI should not be used to replace customer feedback, and collecting feature requests from your customers is certainly the best way to go! How you work is quite similar to what my agency did before I built Userdoc, now it's more like... 1. User personas 2. User stories (with a small amount of detail) 3. Flesh out the acceptance criteria of the users stories via discussions and collaboration with client (or customer) 4. Create user journeys to map how the features will be used and interact with relevant personas