Step 2 · Refine

Requirements, Permissions, and Approval Design When a TMT Startup Introduces Robo Claw

Once the target business is decided, specify the MVP scope, inputs and outputs, target users, SaaS/API connections, minimal production permissions, Secret management policy, approvals, concurrent responsible persons, cost limits, and KPIs.

Conclusion

The purpose of the Refine STEP is to document the target business within an operable range for a small team, specifying 'who, to what extent, and under which approvals automation will be performed.' In particular, clarify production permissions, Secret management policy, cost limits, and approvers (can be concurrent) at this stage. If this remains vague and proceeds to the Pilot, design revisions will occur in later steps.

Who This Is For

Who This Is For

This is targeted at the CTO, development manager, and personnel concurrently responsible for information systems who decided on the target business during the Discover STEP.

What You'll Decide

What You'll Decide in This Step

In the Refine STEP, document the MVP scope of the target business, data handled, connected systems, minimal production permissions, Secret management policy, approval conditions, responsible parties, cost limits, and KPIs, and convert them into requirements that can be validated in Build & Validate.

Startup Challenges

Challenges unique to TMT startups.

01

There is no dedicated person to design permissions

There is no dedicated security personnel to design access permissions or Tool Policy, and the development manager serves concurrently.

02

Rules for Secret management are not established.

In many cases, rules on who manages API keys and tokens and to what extent are not clearly documented.

03

Only one approver can be assigned

Due to the concurrent duty system, it is difficult to establish an approval process with multiple people checking.

04

Difficult to estimate cost ceiling

There is insufficient information to determine how to estimate costs that fluctuate according to usage within a limited budget.

Method

Implementation Steps

1. Organize As-Is/To-Be

We organize by comparing the current business flow with the business flow aimed for after the introduction of Robo Claw.

2. Define the MVP scope and target users

Narrow down the business scope handled in the first pilot, and define the users and teams to be targeted.

3. Design Agents, Skills, and Tools

Design the roles of Agents required for the target tasks, the Skills for business procedures, and the scope of Tools that perform external operations.

4. Define the Tool Policy

Define as a policy the operations that the Tool is allowed to perform (Allow/Deny) within the minimum necessary scope.

5. Design minimal production permissions

Design who can use and modify the Agent to what extent, while restricting direct changes to the production environment.

6. Define secret management policies

Define policies for issuing, storing, and rotating API keys and tokens in a way that can be operated by a small number of people.

7. Define approvers and responsible persons

Even when there are concurrent duties, clearly define release approvers, external transmission approvers, and escalation destinations.

8. Define cost ceiling and KPI

Define the maximum usage cost and the KPIs used to measure effectiveness.

Data & Systems

Data and Systems Used

Product requirements and user stories Tickets Source Code · Pull Request Access rights ledger GitHub and GitLab Linear, Jira, Backlog CI/CD tools

Human-in-the-loop

Where Human Approval Is Required

  • Clearly specify the approver for merging Pull Requests (also indicate position/responsibility if concurrently holding multiple roles)
  • Clearly specify the final approver for external transmission to customers
  • Define the approval flow for issuing and rotating Secrets
  • Define the escalation destination if usage exceeds the cost limit

Measurement

KPI

In the Refine STEP, define candidate KPIs to be verified in Build & Validate

Target level for time spent creating review comments.

Target time for drafting review comments for Pull Requests.

Lead time until approval

Time required from draft creation to human approval

Operational feasibility within the cost limit

Confirm whether operation is within the set cost limit

Checklist

Requirements definition checklist

  • Document the scope of the MVP (included and excluded business operations)
  • Input data and outputs (review comments, draft responses, updates) are defined.
  • Confirm the SaaS/APIs to be connected and whether connection is allowed
  • Define the minimum production permissions
  • Policies for issuing, storing, and rotating secrets are defined.
  • Approval conditions and approvers for Pull Request merges and external communications are defined.
  • Even if concurrently holding multiple roles, clarify the responsible person and escalation destination
  • Define the scope of operation log retention
  • Define the cost limit
  • KPIs used for effect measurement are defined

Pitfalls

Common Pitfalls

01

Omitting permission design

Omitting permission design because the team is small will cause significant rework when the business expands.

02

Proceed without deciding on approvers

If approvers are left ambiguous due to concurrent roles, operation may start with unclear responsibility.

03

Do not set a cost limit

If you start without estimating usage, you may realize the unexpected cost increase too late.

FAQ

Frequently Asked Questions

Who should be responsible for defining the requirements?

It is recommended that members who actually operate the target business (such as the CTO or development manager) take the lead. If external transmission is involved, it is also recommended to get confirmation from management.

How detailed should authority design be?

At a minimum, clearly define the scope to restrict direct changes to the production environment, and the approvers for Pull Request merges and external transmissions. The level of detail should be adjusted according to the risk of the target business.

What happens if too much time is spent on Refine?

Trying to perfect the requirements will delay the start. It is recommended to first solidify requirements that can be verified with a small-scale pilot, with the assumption of reviewing them when expanding to production.

Shall we organize requirements, authorities, and approval design together?

The MVP scope, minimum permissions, approval flow, and responsible person can be concretized through consultation in the official LP.

Organizing the implementation requirements