Analysis tools / Choosing between options
Product explorer
“What should this product actually be?”
Early product definition is where the most expensive decisions get made with the least evidence behind them. The category, the buyer, the performance bar and the constraints are usually settled in a couple of meetings, written into a deck, and then treated as fixed for two years by people who were not in the room.
The discipline
The useful discipline here is not a template, it is sequence. Category before market, because a product for a different category has a different buyer. Market before performance, because the performance bar is set by what the buyer will compare you against. Performance before constraints, because a constraint only bites once you know what it is constraining. And trade-offs last, once there is something real to trade.
Run in that order, the awkward questions surface while they are still cheap to answer. Run in any other order, they surface at the gate review.
How SOSX runs it
Product explorer is a guided session rather than a form. It works through six phases: defining the product category, the target market and use case, the performance requirements, the constraints, the design trade-offs, and a final check on whether the level of detail is enough to act on. Each phase asks the questions that phase needs and holds the answers against the network, so the product being defined stays connected to the systems, actors and flows around it.
The session runs against its own audit database, so the exploration is recoverable afterwards: what was asked, what was answered, and what that changed. Because it happens inside the network, the output is not a separate document for someone to reconcile later. It is part of the model the other analyses read.
What you get
A product definition grounded in the network rather than in a deck, the trade-offs that shaped it recorded alongside it, and an audit trail of the session. Where the exploration raises a question the model cannot yet answer, that shows up as a gap rather than as a confident guess.
The others in this group
Several routes are on the table and one of them has to be argued for.
Trade-off analysis
“Which option wins, and what does it cost us elsewhere?”
Multi-objective comparison across systems or scenarios, with the Pareto frontier drawn and the sensitivity caveats attached.
Compare models
“Which AI model does this work best?”
The same task on the same network, run by several AI backends, with time, cost, carbon and output quality set side by side.
Comparative study
“How do these options compare, fairly?”
Several variants built to one shared backbone, so the comparison is like for like rather than six differently-shaped models nobody can line up.
Or see all the analysis tools. If you would rather we built the model and ran them for you, that is our system research, build and analysis service.