We are trying out some DDD for an upcoming pigweed.dev tutorial. I'm docs lead for the site and I'm working with 5 or so engineers. It's going decently. As a te

We are trying out some DDD for an upcoming pigweed.dev tutorial. I'm docs lead for the site and I'm working with 5 or so engineers. It's going decently. As a technical writer, it's hard to flesh out exact content until the features are built out. Especially in a tutorial, where each section builds off the ones that came before it. So we have a lot of placeholders in the tutorial. All-in-all I think it's been fairly helpful for me to repeatedly say: "This will be our main artifact. This is where people will learn of your features. Please make sure your work and features are captured in this document, otherwise they kinda don't exist (because this doc is where people will most likely learn of the new features)." I don't ask them to fully flesh out docs themselves; I'm just asking them to dump notes into the draft doc and insert commands/code as things become fleshed out. I think it's also a useful focusing exercise for the team - there's so much we could work on but if it's not going into our primary documentation artifact and it's not foundational work that is prerequisite to what we want to show in the tutorial then that sometimes makes it easier to decide that the thing is lower priority. There was also an interesting feedback cycle where the team worked on some really important stuff that is usually kinda "behind-the-scenes" and low-level, and we asked ourselves "we have to work this into the doc and make people aware of it... how do we do that?"