How did you customize your feature statuses, and did it help you manage the process?

  • 3 October 2022
  • 9 replies
  • 86 views

Userlevel 3
Badge +3
  • Product Makers Group Leader
  • 11 replies

I’m considering adding feature statuses to help track and manage our discovery processes, including research, UX design, requirements and stakeholder reviews. Now we do all these things when the feature is a “Candidate”. 

How have you customized your feature statuses?

 


9 replies

Userlevel 2
Badge +1

@ccarney, what are you hoping to achieve? I assume you would like to measure time spent in given statuses and understand where you spent most time so that you can optimise the process, am I right? For this purpose Productboard has efficiency report - https://support.productboard.com/hc/en-us/articles/6869063507603-BETA-Report-Efficiency

In my team we split “discovery” into two parts: “problem discovery” and “solution discovery” - this way we can see where in the “double diamond” we are at given moment, which is enough granularity for us. Having more statuses could mean that people need to update things more often and as we know some team members can forget to update things - happened to me several times. So I would suggest you find a good balance between number of statuses and effort of your users to update things.

Hope it helps.

Badge

@ccarney, we recently went through the same exercise at my company. Ultimately we ended up with the below Feature Statuses and created Tasks for tracking the specific items like the research, UX design, and technical design. I think Tasks would be ideal the stakeholder review, as well. 

 

Userlevel 3
Badge +3

Thanks @miro_remias and @Ashley V. 

I agree that the challenge is balancing the usefulness of the statuses with the effort needed to use them.

Thanks for reminding me of the efficiency reports. I just signed up for the Beta. I have been doing some tracking by hand of how long features remain in each state, and it looks like Productboard will do it for me. 

Interesting that you both have similar approaches: Problem Discovery/Problem Definition and then Solution Discovery/Design. I like the “Ready for Prioritization” status as well. 

@Ashley V. Do your PMs actually put features in Rejected status? I feel like there is reluctance to do this in my organization. Also, do you ever have features that are “Ready for Prioritization” and then go back to Backlog or Rejected?

Userlevel 1
Badge +1

I’m going through this right now as I’m giving a review of our product development process. I had similar statuses to @Ashley V. - slightly different naming. I had originally nixed a ‘Ready for Prioritization’ status, but some of the initiatives that we have going on (attempting a quarterly planning cadence), might make this valuable again. I also hadn’t considered a use case for the “Backlog” status, but feel like I’m going to run up against an issue where the GTM org wants to know if we will ever work on a feature or not. 

My natural inclination is try to have as few statuses as possible (potentially having too few statuses to start). What I have right now: 

  • New Idea - the dump of new ideas 
  • Discover - Defining and understanding the problem 
  • Define - UI/UX Design 
  • In Progress - in active dev 
  • Code Complete - development is done - getting all the launch pieces in place 
  • Released - in the wild 
  • Won’t Do - Something we have no plans to do in the next 18ish months 
  • Blocked - because everyone felt having a blocked status was imperative :-) 

There are few “States” I was thinking about tracking differently - like beta for example. If we are running a beta, I would expect the feature to still in “in progress” so my plan was to track those using tags. Same thing with our UX Research, or Early Access Programs - just with different statuses. 

I like the idea of the backlog as passing some kind acceptance, but I’m worried my GTM org might also take that as more of a “commitment” than is intended. How has your experience been with GTM (or any crossfunctional org) understanding of backlog to be “will absolutely be completed.” 

Userlevel 3
Badge +3

I tell our stakeholders that a feature is not officially on the roadmap until it is in Planned status with a timeframe on it. 

I like the phrasing of “Won’t Do” - much nicer than “Rejected”. 

We started off with states for “Public Preview” and “Private Preview”, but recently removed these and instead we set up new features for the preview and General Availability versions of a feature. Using separate features enables us to plan any extra development work needed (and there is usually more work needed).

Badge +1

Hi! I am going thru exactly the same thing as you are ;) 
I came with those statuses in PB and I want to map them with Epic statues in Jira to change them automatically:

  1. New idea = in Jira EPIC
  2. Ideate 
  3. Design = prototype, review, user testing etc
  4. To do = planned with timeframe added
  5. In progress = dev in progress
  6. Done = development finished
  7. Cancelled = idea after design didn’t work and we are dropping idea
  8. Released

Almost everything looks good but I have a problem because everything what we are doing we are testing with AB tests. Therefore I am wondering how do you track statuses between Done and Released meaning do you track Experiments in PB to keep continuity of the process from Ideation to Release? 
 

I came up with two ideas:

1. I can create a new feature dedicated to Experiments only but it causes lack of continuity and additional work of creating description why and what we are testing because it is already added in the first feature about development.

2. Use subfeatures only for experiments but I cannot filter by subfeatures to get view without Fratures that are assigned to. Plus having dozens of AB tests at the same time is hard to track and map dependencies between them. 


Feedback is more than welcome ;) 
 

Userlevel 7
Badge +13

@OKRs_fun we have a separate status here at Productboard for features being AB tested which sits between Done and Released. Released then represents the final product (and/or winning test) that goes to general availability in production. We also suggest making Cancelled a hidden status (if you aren’t already).

Another option that I’ve used in past companies is considering the work released when in production and move tests into a separate product (you can also tie them to the original feature using dependencies).

The beauty of Productboard is that it’s flexible and allows you to determine the work approach that’s best for you and your team.

Badge +1

Hi @scott.baldwin! Thanks for the prompt reply!
 

I was wondering of adding two statuses after Done: Experiment (test on track) and then Finished (test already finished but waiting for the final summary before release/next iteration). However the problem is that we have multiple markets, 4 sub-products under the same brand and we need to synchronize tests to avoid discrepancies. Therefore seeing timelines specifically for experiment period (not entire feature starting from ideate) is so crucial. 
 

100% agree that PB is fully customizable and I take a lot from this ;)  

Userlevel 7
Badge +13

Yep, that could work too @OKRs_fun. That’s where a separate product where your tests live could be helpful. Then you can have each feature have its own timeline, sub features, and visibility. Alternately, subfeatures in your main product with their own timelines could also be an option.

Reply