Selected work / The operating details
Six artifacts.
A closer look at the work.
Process design, decision gates, dependency handling, leadership trade-offs, and merchant content operations.
Prepared from Grace’s account of her work. Reconstructed designs explain the approach; illustrative scenarios demonstrate how it could operate. They are not original company records or additional claims of achieved results.
01 / From faster development to coordinated delivery
Confirmed scope: AIPDLC, leadership buy-in, five pods of approximately 10 people each, PM gates, Jira/Rovo dependency alerts, formal OKR reviews, and release-process changes. The “before” column is a diagnostic hypothesis, not a verified historical account.
Before / Questions to validate
Where did work wait?
- Idea intake: did requests arrive without a shared problem statement?
- Prioritization: did teams assess requests against separate roadmaps?
- Handoff: did unresolved product questions return to PMs during development?
- Dependencies: did another pod’s work become visible only after an issue arose?
- Release: did coordination lag behind implementation?
Validate using one historical initiative, its Jira events, and the people involved.
After / Confirmed capabilities, reconstructed sequence
Connect context to action.
- Inform: product-insights skills help colleagues decide what to explore.
- Prioritize: individual roadmaps provide context for Jira skills.
- Decide: PM gates support progression through AIPDLC.
- Coordinate: Rovo/Jira identify interdependencies and alert relevant teams.
- Release and learn: adapted release processes and OKR reviews guide improvements.
Design principle: faster implementation increases the importance of clear decisions and visible dependencies. The operating process should help teams act on that information.
Suggested measurement specification
| Measure | Definition | Evidence and limits |
|---|---|---|
| Idea-to-decision time | Median business days from complete intake to a recorded proceed, pivot, or stop decision. | Intake and decision timestamps; include stopped ideas and report the sample size. |
| Issue-to-owner time | Median business hours from a raised issue to acceptance by an accountable owner. | Jira history; distinguish suggested assignment from accepted ownership. |
| Release waiting time | Median elapsed time from engineering completion to production release. | Completed-work and deployment events; compare similar work and report release failures alongside speed. |
These are proposed definitions for the confirmed OKR areas. No baseline or improvement is claimed.
02 / Product management gates
A reusable gate checklist that makes the decision, minimum evidence, and accountability explicit. Grace confirmed PM gates within AIPDLC; the detailed criteria and role assignments below are proposed for review.
| Gate | Decision / minimum evidence | Suggested accountability | If the evidence is missing |
|---|---|---|---|
| 1. Problem worth exploring | Name the user and problem; identify supporting evidence; state a desired outcome. | PM drives; relevant business partner contributes. | Time-box discovery or park the request. Do not confuse a requested feature with an established need. |
| 2. Priority worth pursuing | Explain roadmap fit, expected benefit, dependencies, rough effort, and what would be deferred. | PM and engineering lead recommend; leadership resolves cross-team priority conflicts. | Clarify the trade-off before committing capacity. |
| 3. Approach worth building | Review a prototype or workflow; record feedback, assumptions, exceptions, and open questions. | PM owns the product decision; engineering checks feasibility; users inform usability. | Revise the approach or run a focused test. |
| 4. Ready for engineering | Agree acceptance criteria, boundaries, dependency owners, and decisions required before implementation. | PM and engineering lead jointly confirm readiness. | Return only the missing decisions; avoid restarting the entire review. |
| 5. Ready for release | Confirm test evidence, unresolved risks, communications, support ownership, and recovery approach. | Engineering/release owner coordinates; PM confirms product acceptance. | Resolve the risk, reduce scope, or defer release with a documented owner. |
| 6. Ready for the next decision | Review usage or outcome evidence against the original goal; record continue, adjust, or stop. | PM leads the review with delivery and business partners. | Separate “not enough data” from “not working”; set the next observation point. |
A practical handoff check
Interactive example. Selections stay in this page session and do not update Jira.
0 of 5 readiness checks complete
Keep the process proportionate: use a short documented check for low-risk work and deeper review when uncertainty, dependencies, or customer impact justify it. AI drafts and summarizes; accountable people make the gate decisions.
03 / A dependency alert that leads to action
Confirmed capability: Grace used Rovo agents and Jira workflows to surface project interdependencies and alert relevant teams. This fictional example demonstrates the workflow without presenting an invented incident as Solovis history.
Pod A’s handoff may depend on Pod B’s interface change.
- Trigger
- A work-item update reports that a required response field is not available.
- Evidence
- EXAMPLE-A describes the required field. EXAMPLE-B describes a related interface change and references the same field.
- Affected work
- Pod A’s acceptance criteria cannot yet be validated.
- Notify
- Pod A’s PM and engineering lead; Pod B’s technical owner.
- Uncertainty
- The field match suggests a dependency. The receiving teams must confirm it; no delivery date is inferred.
- Requested action
- Confirm the relationship, assign ownership, and record the next decision in Jira.
1 / Signal: the agent finds an issue and relevant cross-project context.
2 / Confirmation: receiving teams determine whether the dependency is real.
3 / Ownership: a named person accepts the action; the Jira relationship is recorded.
4 / Decision: teams agree whether to change sequence, adjust scope, or escalate a priority conflict.
5 / Closure: the owner records the resolution and affected work is updated.
If the alert is wrong
Record why it was dismissed, correct the source context, and refine the matching instructions. Repeated false alerts should trigger a review of the rule or skill.
If no team responds
Use an agreed follow-up interval and escalation route. Escalate with the unresolved decision and delivery consequence, rather than repeatedly broadcasting the same alert.
Suggested measures: confirmed alerts / reviewed alerts, median issue-to-owner time, and unresolved confirmed dependencies. Do not treat alert volume as business impact.
04 / Adapt release coordination before expanding delivery
A model leadership brief based on Grace’s confirmed work adapting releases for agentic development. The alternatives, pilot design, and recommendation below are illustrative; no executive approval or pilot outcome is asserted.
Question: how should release coordination adapt as implementation accelerates?
Working hypothesis: if development moves faster than readiness decisions and dependency resolution, completed work may accumulate before release. Validate this with engineering-complete and deployment timestamps.
Recommendation: run a bounded pilot of revised readiness checks and dependency ownership before expanding the workflow across all five pods.
| Option | Potential benefit | Trade-off |
|---|---|---|
| A / Retain the process | Lowest adoption effort. | May leave coordination delays unresolved. |
| B / Increase release frequency immediately | More opportunities to ship completed work. | May increase coordination load if readiness and dependencies remain unclear. |
| C / Pilot revised coordination | Tests the process change and exposes adoption issues on a smaller scope. | Requires temporary measurement and rollout effort; broad benefits arrive later. |
Proposed pilot
Two pods, one representative release stream, four weeks. Record a comparable baseline before starting. Confirm the pilot scope with delivery owners.
Leadership commitments
Approve the scope, designate a sponsor, and identify what work can be deferred to create capacity for adoption and review.
Success evidence
Shorter release waiting time with no deterioration in the agreed release-quality measure. Review unresolved dependencies and team effort to understand the result.
Stop or adapt
Revisit the workflow if it adds review delays, produces excessive false alerts, or leaves release accountability ambiguous.
Decision record: capture the approver, decision date, chosen option, accepted trade-offs, owners, and review date.
To make this historical evidence: replace the sample with one actual leadership decision, its supporting information, your recommendation, the decision made, and what happened next.
05 / From merchant imagery to an in-app catalog
Confirmed BakOme ownership: merchant image upload, internal review, image-to-product/store matching, and app display. The interface and exception rules below are a proposed reconstruction, not screenshots or a claim about the shipped implementation.
Fictional sample: Example Store / Sample product. No upload or live merchant data.
Give the image a clear catalog context.
Associate the submission with a store and product before it enters review. Show the merchant whether the upload succeeded and what happens next.
Exception handling makes the workflow complete.
| Situation | Proposed behavior | Product decision to validate |
|---|---|---|
| Unsuitable or missing image | Give the merchant a specific correction reason and a resubmission route. | When is an image required for publication, and when is a fallback acceptable? |
| Incorrect product match | Keep the image out of that product’s display until the association is corrected. | Who can change associations, and what review is required? |
| Replacement after review | Route the new asset through review and preserve the current approved asset until replacement is accepted. | Does every replacement require review or only certain changes? |
| Rejected submission | Show status and the reason; allow a corrected submission without recreating the product. | What information does a merchant need to resolve the issue independently? |
Trade-off worth explaining
Immediate publication reduces merchant waiting time; review can improve catalog consistency but adds operational effort. The portfolio should identify the actual launch choice and why it was appropriate.
Suggested evaluation
Track submission-to-display time, first-pass approval rate, and incorrect-image reports. Separate process measures from marketplace adoption: 300+ users and approximately 20 merchants do not establish image-workflow performance.
06 / The operating rhythm behind the work
This companion makes six product-operations responsibilities concrete. Confirmed experience includes Solovis AIPDLC, formal OKR reviews, roadmap-informed skills, cross-project alerts, reporting, and release improvements; quarterly and PI planning are documented in Grace’s AFS role. QBR ownership, exact meeting frequencies, and ownership of a portfolio-wide launch calendar are not yet confirmed.
A. Define, document, and maintain ways of working
| Working agreement | Proposed standard | How it stays useful |
|---|---|---|
| Intake and ownership | Each request names the problem, intended user, requester, outcome, and initial owner. | Return incomplete requests with specific missing information; keep a visible disposition. |
| Priority and scope | Record roadmap fit, dependencies, effort assumptions, and the consequence of deferring other work. | Revisit when evidence or capacity changes; record the reason for priority changes. |
| Decision gates | Use minimum evidence and a named decision owner at each AIPDLC gate. | Review repeated exceptions and remove checks that add no useful information. |
| Status and escalation | Use agreed status definitions, owners, dates, and an explicit decision needed for escalations. | Check stale entries and unclear ownership during the portfolio review. |
| Process maintenance | Assign a process owner and record version, rationale, and effective date for changes. | Use team feedback and OKR reviews to refine the standard; communicate changes at the next relevant forum. |
B. Coordinate planning, OKRs, and business reviews
Recommended cadence design below. It describes how Grace could operationalize the role; it does not claim that every forum or frequency existed at Solovis.
| Forum / suggested rhythm | Inputs and preparation | Decision-ready output |
|---|---|---|
| Intake and priority review / weekly | PMs submit complete requests and roadmap context; program lead assembles unresolved trade-offs before the review. | Accept, investigate, defer, or decline; each accepted item has an owner and next decision. |
| Cross-pod delivery review / weekly | Pod owners update Jira before the forum; program lead consolidates changes, blockers, dependencies, and launch risks. | Owner and next step for each exception; decisions needing leadership are separated from routine updates. |
| OKR review / monthly, with quarter-end assessment | Metric owners provide actuals, targets, confidence, and evidence; teams explain variance. | Continue, adjust, or stop an initiative; update the improvement actions and follow-up date. |
| PI / quarterly planning | Collect proposed outcomes, roadmap priorities, capacity constraints, and dependencies before planning; resolve conflicts with accountable partners. | Aligned objectives and sequencing, named dependency owners, recorded risks, and a shared plan. |
| QBR / quarterly | Request owner inputs two weeks ahead; consolidate a draft one week ahead; distribute a reviewed pre-read two business days ahead. | Leadership decisions on priorities, capacity trade-offs, major risks, and next-quarter focus; publish the decision log and owners after the review. |
Planning and QBRs serve different decisions. PI planning aligns future delivery work; a QBR reviews business outcomes and determines where leadership should change direction. Report ownership of each separately.
C. Own a portfolio view from intake to launch
A useful portfolio record ties each initiative to an outcome, accountable owner, stage, dependency, target window, and next decision. Jira can remain the status authority while the roadmap and launch calendar provide different views of the same work.
| View | Required fields | Question it answers |
|---|---|---|
| Intake queue | Problem, requester, user, expected outcome, roadmap fit, owner, disposition. | What deserves discovery or capacity? |
| Roadmap | Outcome, initiative, priority, sequencing, confidence, dependencies. | What is next, and why? |
| In-flight portfolio | Stage, accountable pod, health, latest change, dependency owner, next decision. | What is progressing and what is at risk? |
| Launch calendar | Initiative, target window, confidence, readiness state, release owner, communication owner. | What may ship when, and what must happen first? |
Fictional example / Not a live Solovis initiative
Initiative: Example catalog update · State: In flight · Target: Week 4, tentative · Risk: linked interface change not confirmed · Next decision: sequence the dependency or reduce launch scope · Owners: product lead + engineering lead.
D. Make stakeholder updates actionable
Recommended source-of-truth rules: Jira holds work status and ownership; the approved plan holds outcome and scope; a linked decision log holds decisions and rationale; an outcome register holds measurement. Summary pages link to these records and carry a timestamp rather than silently replacing them.
Leadership readout / Reusable template
- Outcome
- What business or user result are we pursuing? What changed since the last review?
- Evidence
- Actual versus target; source date, sample size, and confidence.
- In flight / next
- Current initiatives, upcoming launches, and changes to sequencing.
- Exceptions
- Risks, dependencies, affected dates, and accountable owners.
- Decision needed
- One clear question, realistic options, recommendation, consequence of delay, and decision deadline.
- Follow-through
- Decision owner, action owner, next checkpoint, and outcome to review.
Notify affected Product, Engineering, and partner owners when scope, dates, or dependencies change. Use asynchronous updates for visibility and meetings for unresolved decisions.
E. Build systems that reduce coordination effort
| Confirmed capability | Operating purpose | Suggested evaluation |
|---|---|---|
| Roadmap-informed Jira skills | Bring priority context into discovery and work assessment. | Time to prepare a priority decision; rate of decisions reopened for missing context. |
| Rovo dependency alerts | Surface interdependencies and notify relevant teams. | Confirmed-alert rate and time to accepted ownership. |
| Claude-prototyped internal tool | Improve collaboration, visibility, and earlier issue surfacing. | Active usage, task completion, and time to find the current answer. |
| Loom-supported pod coordination | Share context across delivery teams. | Preparation effort and follow-ups caused by missing information. |
AI output should retain supporting context and uncertainty. People remain accountable for priorities, commitments, and release decisions.
F. Run a continuous-improvement loop
Example improvement hypothesis: clearer handoff criteria could reduce engineering clarification loops. Measure returns for missing requirements alongside handoff preparation time so the process does not simply transfer more work to PMs.
Case-study companion