Technway Hub: Turning Ideas into Decisions and Projects
A case study in Business Analysis: defining the problem, making uncertainty visible, and preserving the reasoning behind a software project.
Selected requirements & acceptance criteriaSee the key business rules, their rationale and testable acceptance scenarios directly in this case study—without opening a second page.Read the evidence- My contribution
- Business analysis, workflow and requirements design, frontend engineering
- Product focus
- Ideas, evidence, decisions and Project initiation
- Current evidence
- Browser prototype and a defined secure V1 scope
The workflow the product needs to support
- CaptureRecord the idea and its owner
- InvestigateSeparate evidence from assumptions
- EvaluateCompare value and uncertainty
- DecideRecord a justified decision
- ConvertCarry the context into a Project
The problem
The reasoning behind a project often starts outside an issue tracker: a problem observed in day-to-day work, an assumption worth testing, or a suggestion whose value is not yet clear. When those discussions and decisions are spread across different places, a team can lose the context that originally justified the work.
I wanted Hub to preserve that context without replacing GitHub, Linear or other specialist delivery tools. It needed to help answer three practical questions:What problem are we solving? What do we actually know? Who decided to proceed, and why?
What I worked on
As Technway's founder, I worked across business analysis and implementation: clarifying the intended users and scope, shaping the Idea lifecycle, defining data and decision rules, writing acceptance criteria, and refining the frontend interactions. This was an in-house product, not a client commission.
The work was deliberately iterative. The browser prototype made it possible to inspect the central journey before committing to the permanent persistence and permission model. The next secure release is specified separately and must pass its own acceptance tests.
Three decisions that shaped Hub
Each decision addresses a real trade-off between collecting enough information to make a sound decision and keeping the workflow practical for day-to-day use.
Make capture lightweight without confusing it with approval
How much information should someone have to provide before an idea can be saved?
- The trade-off
- A detailed form would encourage completeness but could discourage early capture. A single free-text note would be easy to create but difficult to evaluate consistently.
- The decision
- Start with a title, summary and accountable owner. Put problem framing, audience, supporting evidence and validation in the Idea detail, and use a Needs attention view to keep unfinished discovery visible.
- What the current work demonstrates
- The prototype includes the short capture flow, detailed Idea records and an attention view.
Related requirement:Idea capture
Keep evidence, assumptions and scores in their proper roles
How can we compare ideas without treating a hypothesis or a score as a fact?
- The trade-off
- One combined description would be simpler but would hide uncertainty. A numerical score alone could give an impression of objectivity while concealing weak evidence.
- The decision
- Record sources and their strength separately from assumptions and experiments. Evaluate six dimensions to support comparison, but require a separate, reasoned lifecycle decision.
- What the current work demonstrates
- The prototype distinguishes evidence, assumptions, experiments, scoring and explicit status actions.
Related requirement:Independent validation
Make project creation a traceable decision, not another disconnected record
What should survive when an approved idea becomes an actual project?
- The trade-off
- A standalone Project is easy to create, but it loses the original problem and decision trail. Automatically turning high-scoring Ideas into Projects would also bypass approval.
- The decision
- Convert only after an explicit approval. Keep links between the source Idea and resulting Project. For secure V1, define transactional conversion, duplicate prevention and server-side authorization as acceptance criteria.
- What the current work demonstrates
- The browser prototype has linked Idea and Project views. Atomic, authenticated server conversion remains a release requirement.
Related requirement:Approved-only conversion
Selected requirements and acceptance criteria
The decisions above become business rules and testable acceptance conditions. These examples are extracted from the internal specification; they demonstrate analysis and test design rather than a completed secure release.
Capture an Idea without a complete business case
Why this matters. Early capture should be simple, but it must not leave an unowned, ambiguous or untraceable record.
Requirement. An authorized owner can save an Idea with a title, short summary and accountable owner, then develop the problem framing and evidence later.
What must be verified
- Given valid required fields and an authorized owner, saving the Idea confirms creation with a stable identifier.
- Given a missing title or summary, the user receives clear feedback and no incomplete record is created.
Current evidence and boundary: The browser prototype includes the capture and Idea detail experience; durable cross-session persistence requires release verification.
Keep validation results separate from decisions
Why this matters. A hypothesis being tested or scored is not the same thing as an approved commitment.
Requirement. Experiments record hypothesis, method, success condition, result and learning. Updating an experiment cannot silently advance or reject its Idea.
What must be verified
- Given a Reviewing Idea, marking an experiment Inconclusive leaves the Idea in Reviewing.
- Changing experiment results does not automatically approve, reject or convert the Idea to a Project.
Current evidence and boundary: The prototype separates experiments, scoring and explicit lifecycle actions; secure persistence and auditability remain release gates.
Convert approved Ideas without losing their history
Why this matters. Moving from investigation to delivery must not create an orphan Project, duplicate work or an unapproved commitment.
Requirement. Only an approved Idea may create one canonical Project, retaining navigation between the source Idea and resulting Project.
What must be verified
- Given an approved Idea, successful conversion creates one Project in Planning, with reciprocal links.
- Given an unapproved Idea or repeated concurrent conversion, no unauthorized or duplicate Project is created; failed transactions leave records unchanged.
Current evidence and boundary: Linked Idea and Project views exist in the prototype. Atomic server transactions and authorization are specified, not yet verified in a production release.
Verify accessibility across the whole decision journey
Why this matters. Individual accessible controls cannot compensate for broken focus, missing feedback or inaccessible error recovery between steps.
Requirement. The secure V1 journey targets applicable WCAG 2.2 AA criteria from capture through investigation, decision, conversion and recovery.
What must be verified
- Complete the capture-to-Project journey by keyboard, with visible focus, accessible dialogs and no keyboard traps.
- Check names, structure, status announcements, errors and recovery with representative screen-reader and browser combinations, then record issues and retests.
Current evidence and boundary: The accessibility contract is documented; no completed end-to-end conformance assessment is claimed.
The complete internal SRD and its operational records remain private. Actual acceptance test results will need an identified release build, environment and recorded evidence before being reported as passed.
Current state and next validation
The inspected GitHub version demonstrates the main Ideas-to-Projects experience, but the secure private V1 is still being implemented. The distinction matters because a working browser interface is not evidence of production persistence or authorization.
Demonstrated in the prototype
- Idea capture, ownership and detailed context
- Evidence, assumptions and validation experiments
- Evaluation, attention queue and reasoned transitions
- Linked Idea and Project views
Still required for secure V1
- Server-authoritative, durable records
- Authentication and object-level authorization
- Transaction-safe conversion and decision history
- Executed security, functional and accessibility testing
The lesson I will carry forward
A useful system of record begins with a clear decision process. Separating an observation from an assumption, and an evaluation from an approval, made the requirements and failure cases much easier to define.
The next meaningful milestone is a verified end-to-end journey: an authorized owner captures and investigates an Idea, decides, converts it, signs out and returns to the same securely persisted context. The case study will be updated with actual test and release evidence, rather than estimated outcomes.