Promise to preparation
Shared contract: availability, acceptance and order status.
Failure to investigate: the customer is confirmed while the store cannot fulfill.
Readiness evidence: unavailable-item, rejection and cancellation paths.
CASE STUDY 01 / BAKOME
Three journeys.
One connected marketplace.
Product ownership from discovery through public launch across the customer, store owner and driver experience.
My roleSenior Director of Product · D2Soft-IntelScopeCustomer · store owner · driver journeysReach300+ users · ~20 merchants · Maryland
Scope: My work covered the full marketplace journey for three personas, from discovery through public launch. Merchant content was one workstream within that scope. The journey maps and operating controls below are reconstructed examples; exact implementation states and performance are not asserted.
MARKET DISCOVERY / ON THE GROUND
Community demand had to meet delivery capacity.
Research close to the community
Our market research was primarily on the ground. The expansion plan included BakOme representatives in each identified community, creating a local presence as we expanded.
The constraint we encountered
Delivery time depended on the balance between available drivers and orders at any given time. Customer demand alone was insufficient to ensure a reliable delivery experience.
Identify communityPlan local representationAssess merchant + driver coverageReview service reliability before scaling
Community research, the representative expansion plan and the driver/order imbalance are reported experience. Capacity checks and the quantitative model below are proposed ways to evaluate that constraint.
ILLUSTRATIVE CAPACITY MODEL / NOT BAKOME PERFORMANCE DATA
What happens when orders outpace driver capacity?
Capacity: 8 orders/hour. Demand exceeds capacity by 4 orders/hour.
Capacity = available drivers × deliveries per driver-hour. Example: 12 incoming orders versus capacity for 8 means demand is 150% of capacity. This simplified steady-rate model excludes geography, travel variability, batching and merchant preparation. It cannot predict an actual delivery time.
Quantitative issues to investigate across the three personas
| Issue to quantify | Measure | Decision it informs |
|---|---|---|
| Demand exceeds supply | Orders/hour ÷ driver delivery capacity, by community and time window. | Where driver coverage is needed before increasing demand. |
| Long delivery tail | Median and 90th-percentile minutes from order placement to delivery; late deliveries ÷ completed deliveries against the promised window. | Whether to adjust coverage, service area or the delivery promise. |
| Slow driver assignment | Median and 90th-percentile time to assignment; unassigned orders at fixed checkpoints. | Whether dispatch or driver availability is the bottleneck. |
| Store and driver timing mismatch | Driver arrival-to-pickup minutes; ready-to-pickup minutes. | Whether preparation estimates or pickup coordination need improvement. |
| Lost orders | Cancelled orders ÷ placed orders, segmented by stage and reason. | Which availability, delay or handoff problem deserves priority. |
| Support and recovery cost | Support contacts per 100 orders; refund value ÷ gross order value. | Which failures are costly for customers and operations. |
| Expansion without repeat demand | First-order conversion and 30-day repeat-order rate by community; orders per driver-hour. | Whether local expansion has both repeat demand and workable delivery density. |
These are measurement candidates, not additional observed failures or invented historical rates. Segment by community, time of day and order type before drawing conclusions.
01 / End-to-end product scope
The unit of value is a completed order.
A customer needs a dependable order, a store owner needs manageable fulfillment, and a driver needs a clear pickup and delivery. Product operations connects those needs across the entire experience.
Illustrative service blueprint · Read each row as a persona journey; read each column as a shared handoff. These are design scenarios, not a claim that every pictured capability shipped.
Persona / goal
01 · Get ready
02 · Commit
03 · Prepare
04 · Fulfill
05 · Resolve & return
CustomerFind the right item and receive it reliably.
Discover & selectBrowse stores, items, availability and service area.
Place an orderReview basket, address, fees and confirmation.
Understand progressSee acceptance and preparation updates.
Receive the orderFollow delivery progress and confirm receipt.
Get help / reorderResolve missing items, cancellations or delivery issues.
Store ownerTurn demand into accurately fulfilled orders.
Set up the storeCatalog, images, prices, hours and availability.
Review demandAccept or decline an order; surface unavailable items.
Prepare & mark readyCoordinate preparation and communicate exceptions.
Hand off correctlyMatch the order to the driver and confirm pickup.
Reconcile & improveResolve order issues; keep catalog and availability current.
DriverComplete a clear, efficient pickup and delivery.
Become readyComplete onboarding and indicate availability.
Accept a deliveryReview the assignment and pickup context.
Coordinate arrivalNavigate to the store and identify the right order.
Pick up & deliverConfirm handoff; reach the customer and record completion.
Report exceptionsEscalate failed delivery, incorrect address or pickup delays.
Customer places orderStore accepts & preparesDriver picks upCustomer receivesSupport closes exceptions
02 / Portfolio operations across three experiences
Own the seams between the journeys.
Preparation to pickup
Shared contract: order identity, readiness and pickup confirmation.
Failure to investigate: driver arrival and store readiness are out of sync.
Readiness evidence: late preparation, wrong-order and reassignment paths.
Pickup to completion
Shared contract: destination, delivery status and completion.
Failure to investigate: the delivery cannot be completed or is disputed.
Readiness evidence: unreachable-customer and failed-delivery paths.
How this becomes a coordinated product backlog
| Operating activity | Working artifact | Decision enabled |
|---|---|---|
| Unified intake | Requests tagged by persona, journey stage, problem and evidence. | Is this an isolated request or a shared journey failure? |
| Prioritization | Impact, frequency, severity, effort and cross-persona dependencies. | Which improvement best protects completed orders? |
| Roadmap alignment | Customer, store and driver workstreams linked to one milestone. | What must ship together, and what can be sequenced? |
| Launch planning | Shared calendar, owners, readiness evidence and communication tasks. | Are product, engineering and operational partners ready? |
| Feedback review | Support themes, journey measures and release follow-up. | Which process, standard or feature should change next? |
Reconstructed operating model to explain the breadth of the work; these artifacts are not exported historical records.
03 / Define, document, and maintain ways of working
Test the whole order, not only one screen.
Each release needs persona-specific acceptance criteria and a shared end-to-end scenario. A passing customer screen is insufficient if the store or driver receives inconsistent state.
Customer acceptance
Correct order details, clear status and a usable recovery path.
Store acceptance
Accurate order intake, readiness updates and reliable handoff.
Driver acceptance
Correct assignment, pickup identity and completion state.
Below: the catalog-image story remains a worked example of the delivery standard, within the larger three-persona product.
Read the operating decisions and evidence
The proposed standard connects a customer need to acceptance criteria, engineering review, staging evidence, and a release decision. Every transition has an accountable owner and evidence required to proceed.
| Transition | Required evidence | Suggested accountable owner | Hold condition |
|---|---|---|---|
| Story → development | Problem, acceptance criteria, exceptions, dependencies, and scope boundary. | PM with engineering lead | A missing product decision would force engineering to guess. |
| PR → merge to staging | Linked story, peer review, passing checks, documented configuration changes. | Engineering reviewer | Review unresolved or required checks fail. |
| Staging → QA acceptance | Traceable candidate artifact; functional, permissions, and regression evidence. | QA owner with PM acceptance | Material failures or unverified acceptance criteria. |
| QA → production | Approved candidate, release owner, partner communication, recovery plan, and monitoring responsibility. | Release owner | Risk has no accountable decision, or the deployed candidate differs from the tested one. |
Standards need an owner after they are written.
Maintenance mechanism: assign a standard owner, version the checklist, log the reason for each change, and publish the effective date. Review repeated exceptions during the improvement review.
Proportionality: use a short check for routine changes and more evidence for changes with higher uncertainty or customer impact. Keep product acceptance distinct from technical release approval.
These are proposed operating controls. They should not be read as verified BakOme branch-protection, test-automation, or approval settings.
04 / Operating cadence and launch planning
Show what is next, what is ready, and what is at risk.
Read the operating decisions and evidence
The release calendar provides a shared view of target windows. A go/no-go decision converts a target into an approved release only when the required evidence is available.
| Operating forum | Inputs to coordinate | Decision / output |
|---|---|---|
| Priority and scope review | Customer, store owner and driver needs; shared roadmap, capacity and dependencies. | What to build, investigate, defer, or stop; owner and next step. |
| Delivery and readiness review | Story status, PR/build evidence, QA exceptions, partner readiness. | Resolve blockers; revise scope or target window; assign escalations. |
| Launch go/no-go | Tested candidate, unresolved risks, communications, recovery ownership. | Release, hold, or reduce scope with a recorded rationale. |
| Post-launch learning | Order journey failures, support themes across all three personas, operating effort and outcome measures. | Follow-up improvements and changes to the delivery standard. |
These forums describe a proposed operating rhythm for the reconstructed example. Specific meeting frequencies and ownership are not asserted as historical achievements.
05 / Planning, OKRs, and leadership decisions
Use the readout to make a decision.
Read the operating decisions and evidence
A leadership readout should expose cross-persona launch risk, its customer impact and the decision needed.
REPORTED ROADMAP DECISION / NOT YET A DELIVERY OUTCOME
Pursue a decentralized SaaS model within available funding.
- Problem
- Delivery times were affected by the balance between drivers and incoming orders.
- Constraint
- The company lacked the financial capacity to build a proprietary algorithmic delivery-coordination model.
- Direction
- The roadmap includes a decentralized SaaS model as the planned response to that constraint.
- Trade-off to test
- Reduce the need for a centrally built coordination algorithm while determining how local execution can maintain a consistent customer experience.
- Validation needed
- Define the SaaS customer, local operator responsibilities, order and driver coordination, support ownership and service-quality standards.
- Outcome status
- Roadmap direction, not a shipped solution. Delivery-time improvements and commercial results are not yet claimed.
How planning differs from the business review
Planning sequences the next work. An OKR review tests progress toward outcomes. A QBR brings outcome evidence, delivery constraints, and strategic choices together for leadership. They may share source data but need different agendas.
Grace’s PI and quarterly planning experience is at AFS. At Solovis, she formally reviewed OKRs and coordinated team metrics and product insights for QBRs and executive readouts.
06 / Evidence and learning
Public launch is established. Workflow impact needs its own evidence.
Read the operating decisions and evidence
300+ users
Reported local marketplace reach, not a daily-active-user measure.
~20 merchants
Reported merchant base in Maryland.
3 personas
End customers, store owners and drivers across the marketplace journey.
What I would measure across the marketplace
Customer: checkout-to-completed-order rate and issue resolution time. Store owner: acceptance time, readiness accuracy and order error rate. Driver: pickup wait, delivery completion and exception rate. Shared: cancellation reasons, end-to-end order time and support contacts per order.
These are proposed measures, not reported improvements. Baselines, event definitions and comparable cohorts are needed before attributing any change to the operating model.
FUTURE ROADMAP / PROPOSED OPPORTUNITIES
Instrument the journeys. Improve reliability. Expand deliberately.
Future direction, not shipped functionality or committed delivery dates. Sequence and scope depend on evidence, technical fit and capacity. Pendo integration is a planned opportunity to evaluate.
Strategic direction: decentralized SaaS. The roadmap responds to a real driver-capacity constraint and limited funding for a proprietary algorithmic model. Product analytics, delivery visibility and community expansion should support validation of that direction.
Explore the decentralized SaaS direction
Define the SaaS customerClarify local operating ownershipPilot coordination workflowsEvaluate service reliability
Working hypothesis: software could enable coordination closer to local operators rather than require BakOme to build a centralized algorithmic capability first. This is an interpretation to validate, not a finalized architecture or commercial model.
Key decisions: who uses and pays for the software; who manages drivers, service promises and exceptions; and which shared data and standards maintain consistency across communities.
Pilot measures: assignment time, pickup wait, on-time delivery, support contacts per order and operator adoption. Define acceptable service thresholds before wider expansion.
Pendo integration
Evaluate product analytics and targeted in-app guidance across customer, merchant and driver experiences.
Questions: Where do users abandon key tasks? Which features are adopted? Where do new users need help?
Decision gate: validate SDK compatibility, cost and event accuracy before wider rollout.
Activation & delivery reliability
Use journey evidence to prioritize onboarding friction, order-status clarity, pickup coordination and driver-capacity visibility.
Measures: first successful task, assignment delay, pickup wait and delivery-promise accuracy.
Decision gate: demonstrate improvement without increasing cancellations or support burden.
Community expansion
Support the representative expansion plan with community-level demand, merchant readiness and driver coverage.
Measures: first-order conversion, repeat orders, on-time delivery and orders per driver-hour.
Decision gate: establish dependable service before widening the launch area.
Pendo measurement plan across the three personas
| Persona | Journey to instrument | Decision supported | Potential in-app guidance |
|---|---|---|---|
| Customer | Store discovery → item selection → checkout → confirmed order; feature adoption and repeat visits. | Which step creates avoidable drop-off? | Contextual help for checkout or a newly introduced ordering feature. |
| Store owner | Store setup → catalog completion → availability setup → first accepted order. | What prevents a merchant from becoming ready to fulfill? | Setup guidance for catalog, images and order handling. |
| Driver | Onboarding → available status → assignment acceptance → pickup confirmation → delivery completion. | Where does a driver need clearer information or assistance? | Task-specific guidance before starting work or while safely stationary. |
Proposed instrumentation, not an assumption that every event is collected automatically. Product interaction data should be reconciled with authoritative order and dispatch records for operational outcomes.
Integration readiness and success criteria
Define events & persona IDsValidate supported SDKTest in stagingPilot one journeyReview & expand
Agree event definitions, a stable identity scheme, role-based segmentation and ownership of dashboards. Test completeness, duplicates, timestamps and app performance before using the data for decisions. Avoid sending payment details, precise delivery addresses or unnecessary personal information in analytics metadata.
Start with one meaningful funnel and a baseline. Assess whether the resulting insight changes a product decision; evaluate any guide against task completion, support contacts and dismissal rates. Set targets after the baseline is established.
Pendo supports analytics and in-app guides on web and supported mobile frameworks; fit and entitlement require validation. Pendo implementation options ↗ · Mobile implementation planning ↗
Grace Bakalag / Selected work