A life of a feature starts with an idea, normally something like “Oh, how cool it would be if we could do this” or “We need this to do that.” So, each little feature on your favourite website or an app existed first in someone’s mind, chances are that that someone was another PM, just like me. Here, I’d like to document this process that brings an idea to a production feature.
For the sake of the story I’ll use a real-life example, something I worked on just recently — a Scholarship Application Management Tool. At ScholarshipOwl, which is where I work as a PM, we realized that we desperately needed to update our scholarship application tool, that is, our main product. Each time I get an idea for a feature, or a request for one, I start by writing a Product Requirement document, I use a Confluence template for this. Here, I’d specify the goals, on our exampleof the Scholarship Application Tool , a goal would be to enable users to manage their scholarships applications from eligibility to application submission . Here, I go and list as many goals as possible, however, I keep them very targeted. Once that’s done, I go on to specify the backgroundandstrategicfit, in my case, the strategic fit was to implement a Scholarship Application Management Tool and thus increase transparency of the scholarship application process. At this point, I think of all the assumptions, for example, our tool will improve scholarship application process transparency, list as many as you please, don’t be afraid to be slightly delusional, here. Perfect! Assumptions done!
Confluence Product Requirement Template
Moving on, now, lets specify the ingredients i.e. requirements for our Scholarship Application Management Tool. First, it’s obvious that this feature is a real monster, it’s clearly not possible to bring it to life with one design and one user story, it will just have to be thought out and implemented in bits, these bits are known as a part of an Elephant Capriccio. No need to be worried, no animals were harmed in the process of making our Scholarship Application Tool, Elephant Capriccio is simply a term used to indicate splitting of a complex feature into smaller features that comprise it. Let’s start with our requirements, I go on and list all the features needed to make the Scholarship Application Management Tool, for example, ability to view scholarships user is eligible for, ability to views scholarship details, ability to filter eligible scholarships, ability to sort through eligible scholarships, ability to pick favourite scholarships, ability to complete scholarship application requirements, ability to write essays, ability to upload files, ability to submit applications, ability to view sent applications, ability to receive feedback from scholarship providers and so on. Clearly, this is not a complete list of features, but you get the main idea.
Jira’s Agile Product Board
Now let’s make some designs of our monster feature. Alright, on to Jira’s Product Board. Personally, I love having a space to manage product tickets that I share with our designer as it keeps our work organized and clearly prioritized, but I also like a very basic boarad for this. Here, I create tickets for each screen needed for our Scholarship Application Management Tool. First I define what’s needed on each screen, for example, ability to view scholarship details, I go on and be as specific as possible, meaning, scholarship title, about scholarship section, requirement type, requirement title, requirement description, requirement details and so on. I go ahead and add wireframes of whatever I had in mind, here as well. Now’s the time for designer to work the magic. I can now kick back an relax, this is a little lie I tell myself, the reality is I’ll repeat this for each slice of the capriccio and then I’ll just move on to the next Elephant Carpaccio. Once designs have been finalized, they go through a review process, probably a couple of more iterations, but eventually they’re done. This means we’re done with it, right? Wrong! We’re just getting started.
A User Story
The time has come to prepare our feature for the the development team. I’d normally go to development team’s Jira Board and create a User Story, or more likely, a whole bunch of user stories. In the process of creating our Scholarship Application Management Tool I’ve created over 30 user stories. Using our example, a story would be something along these lines “As a user I want to be able to learn details of a scholarship application, therefore I need scholarship details section implemented” Perfect! Now, fill in those technical details, attach relevant designs, and hand it over to the development team. Repeat the process unitl you cover every bit of that carpaccio. After, tireless coding and testing our mythical feature is alive, or just live. It’s on productionand it’s time for a little party. Work’s done! Wrong! :)
Documentation
On to the next and final step in the process, it’s time to document document your baby. So, back to Confluence again where I like to keep a documentation section. Here, I’d go on to specify how a feature should behave, I’d add relevant details and designs so that this document can be referenced in case of any possible bug, unexpected behaviour, or also, when a new team member joins they can get all the info needed to maintain it. After this process if repeated for each little feature, I can consider my work done. Well, done here anyway.
So, that’s how a feature gets from an idea, to a product requirement definition, to design, to a user story, to development, to production, to documentationarchive and starts living its life happily ever after. I wouldn’t be a PM if I didn’t use this opportunity to brag about what wonderful people I work with helped me bring to life (see screenshot above).
No comments