What the week actually looks like
A typical week mixes interviews, triage, spec writing, and internal demos. Each produces a different artifact, and each has a different standard of proof.
Interviews need verbatim notes. Triage needs a reason and a frequency. A prototype needs a real workflow and a way to tell whether it helped.
Tag feedback by the reason
Tag each request with the reason behind it: missing data, slow process, unclear ownership, or a broken handoff. A feature name is not a reason, and a reason is what you can actually solve.
When ten requests share one reason, build around that reason rather than around the loudest request. This is also the fastest way to say no without dismissing the person.
Build the smallest working version
Choose one reason and build a tool that handles only that case. It can be ugly. It has to be usable on a real task by the end of the week, or it will never get real feedback.
Keep the prototype next to the feedback that produced it. When someone asks why it works that way, the reason is already there.
Keep a decision log
Write down what you decided, what you rejected, and what evidence would change your mind. Product decisions age badly when the reasoning is lost.
The log also protects the team: a rejected request with a reason is easier to revisit than an argument you have to relitigate every quarter.
What to measure
Measure whether the tool is used on real work, not whether it was shipped. Then measure the time it saved and the rework it avoided.
For feedback work, track how many requests now have a reason attached. That number predicts how good the next prioritisation will be.
How to run it on Sigla
Keep the feedback, the decision log, and the prototype in one workspace. Describe the repeated reason, build the smallest version, and let colleagues use it on their own tasks. Ask for changes by naming the case that broke.
To go deeper on the build, read build an internal tool without coding. If the feedback comes from analysts, the no-code app builder for analysts is the closest path.
FAQ
Does this replace a roadmap?
No. It replaces some speculative work with a small prototype. The roadmap still holds the bigger bets.
Do I need to know how to code?
No. You need a clear reason and a real task to test against. The implementation is something you review by using it.
What makes a good first prototype?
One reason, one workflow, one week. If it needs three workflows to be useful, the scope is still too large.
How do I get engineering on board?
Bring the prototype plus the evidence: who used it, what it saved, and what it does not do. The boundary is what makes it credible.