Product Development
Part of Creator brand product expansion
Choosing a second product from observed customer needs
Use post-purchase reports and buying situations to choose a credible second product without treating suggestions as orders.
Choose a second product by tracing a repeated customer task to an offer the current range does not meet. Start with what buyers have done and asked after using the first product. A follower’s suggestion may reveal an idea, but popularity alone does not show buyers will choose it.
Separate requests from needs
Collect questions from customer service, reviews, returns and buyer conversations. Note the product version and purchase context where known. Group reports by the task behind them, not just the item someone proposes. A request for a larger version, for example, could concern capacity, access or a different use setting, so those problems may call for different solutions.
For each candidate need, record who raised it, what they were trying to do, their current workaround and the consequence of the gap. Keep customer reports separate from follower comments. Neither group represents every potential buyer, and one detailed request need not be common.
Check whether the need belongs beside the first product
Ask whether the proposed item helps an existing buyer complete a related task, serves another buyer the brand can credibly reach, or merely shares the creator’s name. A close companion may use familiar materials and channels. A different category may introduce new suppliers, service questions and product rules.
Write a working case: Customers using [current item] encounter [observed situation]; the proposed item would help them [specific action] where their current alternative falls short. Mark each untested part as an assumption. This sentence is a selection tool, not a product claim ready for promotion.
Compare candidate needs
For each candidate, ask:
- How many distinct, relevant reports exist, and over what period?
- Do they describe the same problem or several preferences?
- What alternatives and workarounds do customers use?
- What would the business need to develop, check, stock and support?
- What evidence would change the decision?
When records allow it, show the number of reports alongside the number of customers or orders that could have produced them. Support contacts are a selected group; silence from other customers does not establish satisfaction. Use the records to compare explanations, not to manufacture a demand rate.
Evaluating candidate needs: Key metrics to track
- Number of distinct reports
- Count unique instances across time
- Time period covered
- How long have these issues been reported?
- Alternatives used
- What do customers currently use instead?
- Development effort required
- Materials, suppliers, compliance checks, support needs
- Evidence that could change decision
- New data from testing or market shifts
Investigate the proposed solution
Speak with buyers who raised the issue and relevant people who did not. Ask about a recent instance of the task before showing a concept. Then give each person the same description, expected contents, likely price and meaningful limits. Ask what they would choose instead and why.
An identified prototype can help examine the task it was built for; observations remain tied to that version. If a saleable item and supportable supply terms exist, an order records a choice at those terms. A waitlist entry usually records a request for an update under the terms shown. Do not project a small, self-selected response across the creator’s following.
Make the choice
Proceed to bounded development when the need is clear, the proposed offer remains plausible beside real alternatives and the team can investigate its delivery requirements. Revise when customers recognise the problem but reject the format or terms. Stop when the link between observations and the item remains weak. Keep the original reports with the decision so later changes can be judged against the need they were meant to serve.
