Hi Sarah. I just wanted to thank you for this article. I know it's a couple of years old now but it was exactly what my team needed to start formalizing our requirements. It's helping us be full participants in product launches as opposed to just support staff for Product and Engineering. Thanks again!
I'm glad to have been a part of you debuting this. Lots of good material going on here.
I'm curious to know what teams out there may have implemented similar methodologies - I've done similar in the past, I know many others who have been 'Heads of BI' or 'Heads of Data' have done similar.
The first generation of the canvas was the Information Product Brief, which was in a document rather than canvas pattern, so in a similar style to the ARD (I think).
Thank you for sharing, and I appreciate the structure of an "information product". I think it does align, but is missing a few pieces the ARD addresses: the timing of when to loop in analytics. I would argue a data product is rarely the central product, rather a piece of the puzzle in a larger product that needs measurement or reporting on it.
Sarah, do you recommend a separate Metrics Catalog to track the ongoing data required to support Product Goals? Something like Analytics Requirement Document => Decision to include in Metrics Catalog => Add to steady state Metrics Catalog (and report)
I treat ongoing monitoring a bit differently. There's been a movement around a "metrics" or "semantic" layer, documented in a "data catalog" or "knowledge repository". Whatever you call it, I think it's a related problem solved differently.
The reason I think it's so different is that it's very hard to say whether product metrics that matter at launch will actually matter 1 year later. In the meantime, I like to keep the temporary.
Hi Sarah. I just wanted to thank you for this article. I know it's a couple of years old now but it was exactly what my team needed to start formalizing our requirements. It's helping us be full participants in product launches as opposed to just support staff for Product and Engineering. Thanks again!
I'm glad to have been a part of you debuting this. Lots of good material going on here.
I'm curious to know what teams out there may have implemented similar methodologies - I've done similar in the past, I know many others who have been 'Heads of BI' or 'Heads of Data' have done similar.
Likewise—all ears to hearing others who have implemented similar and how it went 👀
Awesome article!
Would love your feedback on our Information Product Canvas.
https://shagility.substack.com/p/information-product
Whats missing, what do we need to explain more?
How do you think it aligns with the ARD?
The first generation of the canvas was the Information Product Brief, which was in a document rather than canvas pattern, so in a similar style to the ARD (I think).
Thank you for sharing, and I appreciate the structure of an "information product". I think it does align, but is missing a few pieces the ARD addresses: the timing of when to loop in analytics. I would argue a data product is rarely the central product, rather a piece of the puzzle in a larger product that needs measurement or reporting on it.
Sarah, do you recommend a separate Metrics Catalog to track the ongoing data required to support Product Goals? Something like Analytics Requirement Document => Decision to include in Metrics Catalog => Add to steady state Metrics Catalog (and report)
I treat ongoing monitoring a bit differently. There's been a movement around a "metrics" or "semantic" layer, documented in a "data catalog" or "knowledge repository". Whatever you call it, I think it's a related problem solved differently.
The reason I think it's so different is that it's very hard to say whether product metrics that matter at launch will actually matter 1 year later. In the meantime, I like to keep the temporary.