SM-001Srdan Mijuskovic
~/process
SM-AGENTOPERATING MANUAL

How I Work

Four phases. The logic is simple: figure out the real problem before you build anything, build the smallest thing that gives you signal, validate that signal with real users before spending real money, then ship and stay until it actually works.

01
DIAGNOSE
Figure out what is actually broken
TYPICAL DURATION: 1–2 weeks
WHAT I DO
  • Talk to the people doing the work, not just the people who commissioned it
  • Ask what decisions people are making today with bad or missing information
  • Find out if the stated problem and the real problem are the same thing (they usually are not)
  • Write down what "this worked" looks like before anyone opens a laptop
WHAT I DON'T DO
  • ×Trust the brief without questioning it
  • ×Start sketching solutions before I can explain the problem back clearly
  • ×Pretend I know the answer in the first meeting
02
PROTOTYPE
Build something real in days, not months
TYPICAL DURATION: 1–3 weeks
WHAT I DO
  • Use whatever gets signal fastest: Streamlit, n8n, a raw API call, a spreadsheet with a formula
  • Put it in front of actual users with actual data
  • Write down what it proved and what it did not
  • Kill it early if the signal is bad
WHAT I DON'T DO
  • ×Spend three weeks on something that should take three days
  • ×Skip straight to a production build because the idea feels obvious
  • ×Show it only to the people who already believe in it
03
VALIDATE
Get honest signal before spending real money
TYPICAL DURATION: 2–4 weeks
WHAT I DO
  • Set a clear bar upfront: this is what success looks like, this is what failure looks like
  • Run it with a small group who will tell me if it is not working
  • Track one or two metrics that actually reflect the problem, not vanity numbers
  • Make the call to proceed or stop based on what the data shows
WHAT I DON'T DO
  • ×Let enthusiasm substitute for evidence
  • ×Validate only with the team that built the thing
  • ×Treat "nobody complained" as proof it is working
04
SHIP
Delivery is not the finish line
TYPICAL DURATION: Depends on scope
WHAT I DO
  • Write specs that engineers can actually build from
  • Set up monitoring before launch so we know on day one if something is off
  • Keep stakeholders updated with honest progress, not polished status theatre
  • Stay until the numbers confirm it is doing what we said it would do
WHAT I DON'T DO
  • ×Call it done at deployment
  • ×Let scope grow quietly without naming it and making a decision
  • ×Hand off and disappear
01
DIAGNOSE
1–2 weeks
02
PROTOTYPE
1–3 weeks
03
VALIDATE
2–4 weeks
04
SHIP
Depends on scope
Each phase gates the next. You can exit early but you cannot skip ahead.
FMT-AAdvisory Call

Sixty minutes. You bring a specific problem you are stuck on, I bring pattern recognition from shipping AI products across several contexts. No prep required, no follow-up commitment.

Good for: early-stage questions, gut checks, getting unstuck on something concrete
FMT-BProject Sprint

Two to six weeks with a defined problem, deliverable, and success metric agreed upfront. I run through the four phases and hand off with everything written down so it does not live in my head.

Good for: prototype builds, strategy docs, product diagnoses
FMT-CEmbedded

Part-time or full-time for a sustained period. I work in your tools, join your standups, and operate as product leadership. Useful when you need someone doing the job, not just advising on it.

Good for: teams scaling AI products, interim PM coverage, longer builds

Start with a call.