Hi @team ! I just finished reviewing the changes to our discovery process (including our decision to pattern our discoveries after product proposals) and want to let you all know it seems to be going well! However, I noticed that it has created some ambiguities in how we create discovery documents when what we’re going over isn’t a scoped feature.
To address this I’ve updated the instructions section of the discovery template to help you decide how to handle these cases. Please boop the poll entry below once you’ve given them a read-over, and comment here if you have any further feedback!
Hey @Fox, thanks for kicking off this thread and pushing things forward! Just wanted to share some thoughts…
Since the template is based on the Product Proposal template used by the Open edX community, I think it makes sense for our internal Product team to be more involved in the early stages (which I know we’re working towards), but maybe the Discovery Instructions can make that clearer.
I’m thinking we could have two assignees: one technical and one product person. For smaller discoveries, maybe it’s just a technical assignee and a product reviewer. Product brings a different skill set - we focus on clarifying the problem, ensure everything aligns with business goals, and keep user needs and design in mind. This helps balance the technical side with the bigger picture of what we’re solving and why.
In keeping to our commitment to great user experiences, all user-facing discoveries must have a product design phase. This phase happens after the initial discovery phase and is to be included in the discovery’s estimations. This phase involves the creation of a product specification, wireframes, and designs.
All discovery tickets should have a product team reviewer. To obtain the estimates for this design phase, consult with this product team member.
I forgot to check if recent discovery tickets all actually had a product reviewer assigned-- but now that I’m reminded, I’ll be sure to be doing that more deliberately. cc @jordan
Oh yes, thanks for the reminder. A lot of the time more than a review is needed, the product team needs to define a lot of the discovery - take the recent [Proposal] Notifications for LMS and Studio. So perhaps we need to revisit this and make it clearer that it needs to be a collaboration, not just a review? And perhaps it would be a good idea to reiterate that in the Discovery Process instructions?
@Fox I read the instructions, but imho if I had to do a discovery, I would be a bit fuzzy about what to do after reading them…
Could we figure out a more straighforward approach - like getting all the discoveries reviewed by @Ali and @cassie , even if it’s a quick read in 5 minutes when it really doesn’t need product/UX input? At least this way it would be simple for everyone to know what to do (just like all code needs a dev reviewer, all discoveries need a product/UX reviewer), and @Ali@cassie can be more aware of what we do, and figure out where to focus their efforts?
We’re already required to add Ali and Cassie as reviewers to discoveries (though as mentioned above, it looks like we may not have been following this as closely as we should.) Would you suggest we just keep things as they were and explicitly indicate that not only should Ali and Cassie review from a general product perspective, but also from a format perspective of the resulting document?
Yes, that approach sounds ideal to me. In some cases, we may need to provide extensive input into the document, while in others, a simple review might be okay. My aim is a more collaborative approach with the technical team. @Ali do you agree?
I agree. The community is moving toward a more product-first approach, so I think it makes sense for our Discoveries to include both a product focus and a technical plan. This will make them more accessible to both technical and non-technical clients and community members. It will also make it easier to convert Discoveries into product proposals when the time comes.
@Fox Yup, that sounds good You could still mention that there might be cases where there isn’t much use for the full product template, but that it is something to discuss with @Ali@cassie . This way there is no guess work on this for the person doing the discovery, while still keeping some flexibility on the format of the discovery.
You could still mention that there might be cases where there isn’t much use for the full product template, but that it is something to discuss with