PM Methods for Supply Chain Software

PM Methods for Supply Chain Software

The craft of product management at Tightly is different from building a consumer app, a growth SaaS dashboard, or an AI chatbot. The decision loop is slower. The user base is smaller, more expert, and higher-stakes. And a bad feature shipped at the wrong moment can cost a customer thousands of dollars in a single inventory cycle.

These differences require specific adaptations to standard PM methods.

The decision loop is slow: Most product improvements are validated through usage — do users engage with the feature? In supply chain software, the meaningful decision happens monthly (when a PO is placed) or quarterly (when a buying plan is reviewed). A feature you ship in January may not have meaningful outcome data until March. This means:
- Build leading indicators (did the user engage with the feature?) alongside lagging outcomes (did PO accuracy improve?)
- Don't declare a feature successful at 30 days. Use 90-day outcome windows.

The user base is small and expert: Tightly may have 200-500 active customers. Discovery requires talking to the actual users — you cannot rely on statistical significance in usage data the way a consumer PM might. Each customer relationship matters. A churned customer at this scale is a significant revenue event and a meaningful signal.

Mistakes have real financial consequences: A bug that generates incorrect reorder quantities can cost a customer $10,000-$50,000 in bad inventory decisions before they catch it. This means:
- Edge case specification must be done in PRDs, not discovered in production
- Rollout strategy matters — new models and calculation changes should roll out to a limited cohort first
- Error states must be designed as carefully as happy paths

For every feature you're considering shipping, ask: would an ops manager use this the first Monday of every month?

The first Monday of the month is when operations teams review inventory health, generate POs for the upcoming cycle, and plan supplier orders. It's the highest-intensity workflow moment in the supply chain calendar. If a feature would genuinely improve that morning for your most active user, it's worth building. If it would go unnoticed, reconsider.

Applied practically:
- *Daily active users dashboard*: Would an ops manager open this on the first Monday? Probably not — they already know what they're doing. Medium priority.
- *Recommended POs with confidence intervals*: Would an ops manager use this when reviewing reorder suggestions? Yes, directly. High priority.
- *Supplier lead time drift alert*: Would an ops manager care if their primary supplier's lead time increased 8 days since last month? Absolutely — it changes every PO they need to place today. High priority.
- *Gamification / streak features*: Would an ops manager engage with this on the most important ops morning of the month? No. Table stakes for consumer; irrelevant here.

This test doesn't override JTBD or discovery — it's a fast sanity check when you're evaluating the relative urgency of features already in the backlog.

Standard PRD templates assume happy path and a few error states. Inventory features require up-front specification of edge cases that will definitely occur in production — and where the wrong handling has financial consequences.

Required edge case specification for any replenishment feature:

Zero-demand SKUs: A SKU that has sold 0 units in the past 60 days. Should Tightly recommend a reorder? Usually no — but there are valid reasons a brand may want to maintain safety stock on a zero-demand SKU (it's a component of a bundle, it's out of stock as the reason for zero demand). The PRD must define the behavior.

New product launches: A SKU with zero historical data. What does Tightly recommend? The PRD must define the cold-start behavior: use category average? Use similar SKU data? Surface a "not enough data" state rather than a potentially wrong recommendation?

Clearance items: A SKU the brand is actively trying to sell through and doesn't want to reorder. Does Tightly know this? How? Does the brand mark it in Tightly, or does the system infer it from a price drop signal? The PRD must define the signal and the behavior change.

Bundle components: A SKU that's also a component of a bundle. The demand signal is a mix of standalone and bundled sales. Blending them naively produces wrong forecasts. The PRD must define how bundle demand is decomposed.

The rule: if a supply chain PM says "we'll handle edge cases in a follow-up sprint," they're shipping a product that will silently generate wrong recommendations for a meaningful subset of customers. Edge cases in supply chain are not edge cases — they're standard operating conditions for brands with complex catalogs.

In supply chain software, the product is only as good as the data feeding it. An ops manager who has misconfigured a supplier's lead time will get wrong recommendations. A brand that hasn't tagged their seasonal products will get inaccurate seasonality modeling. Data quality is not an onboarding problem — it's a retention problem.

Building a data health score for customers:
Tightly should surface a customer-facing data quality score across key dimensions:
- *Supplier completeness*: % of suppliers with configured lead times and MOQs
- *SKU tagging coverage*: % of active SKUs with category/seasonality tags
- *Historical data depth*: How many months of Shopify order history are loaded?
- *Location configuration*: For multi-warehouse brands, % of inventory assigned to a location

A customer with a data health score of 40% will have significantly worse forecast accuracy than one at 85%. Surfacing this score — and showing which specific gaps to fix — converts a frustrating product experience into a guided improvement path.

Why onboarding data quality predicts retention: The first 30 days of a Tightly customer's experience are disproportionately important. If the first PO recommendations are widely wrong (because supplier data wasn't configured), the brand will lose trust before the model ever has a chance to demonstrate accuracy. The PM implication: data health completion should be a first-week activation requirement, not a "nice to have" in a setup wizard.

Instrumentation strategy — what to track in a replenishment product:

Beyond tracking, instrumentation is about building a closed feedback loop: model makes recommendation → buyer accepts or overrides → outcome is observed (actual vs. forecast demand) → model retrains on the error. A PM who doesn't ensure this loop is instrumented is flying blind on model quality.

Stakeholder management at <30 people:
At a small team, formal stakeholder management rituals (weekly steering committees, RACI charts) are overhead. What works instead:

• *Engineering*: Write PRDs that include edge case specification, so engineers don't have to interrupt you mid-sprint with "what do we do if the SKU has zero demand?" Attend sprint reviews, not just planning.
• *Data science*: Frame model improvements as retention metrics, not technical achievements. "This model change is expected to improve PO acceptance rate by 8 points for seasonal brands" is a more useful framing than "we improved MAPE from 22% to 18%."
• *Customer success*: CS is your discovery partner. Train them to log specific workflow moments in their customer calls, not just satisfaction signals. A monthly 30-minute review of CS call notes is worth more than a quarterly NPS survey.
• *Founders*: At an early-stage company, the founders will want to weigh in on roadmap. The way to earn prioritization authority is to make your reasoning legible — show your data, your customer evidence, and your trade-off logic. PMs who present roadmap decisions as mandates lose alignment; PMs who show their work earn trust.