Data exchange is integral to every business partnership. Yet data exchange practices today are highly manual, prone to data leaks, difficult to validate, inherently impossible to monitor, and costly to audit. We're building General Folders to enable secure, secure, and auditable data exchange.
Nice post, still looking it over, but like the format.
Three questions for now; please feel free to ignore any you’re not interested in replying too:
(1) As the title states, topic is enterprise B2B product development. Have you seen any similarly formatted posts on consumer product development? If not, based on your experience what are the likely most common major differences?
(2) Clearly you’re actively practicing B2B product development and as noted in footer got feedback, but curious if you did any research specifically for the post and anything notable that inspired the post and/or patterns you noticed that were helpful in doing research; for example, noticed when research overly broad topics, like B2B sales, that appending “table of contents” was frequently useful.
(3) Are you aware of any open source projects that openly manage product development? Related to question already posted here:
(1) I haven't but I'm sure there are many blog posts covering methods to build enterprise products people want. With respect to this particular categorization, I haven't seen one. Ones I've seen usually tackle a single category. For example, they will talk about when bundling is the right choice vs not. Or how to make it easy for customers to buy a product via PLG, etc.
(2) I should add a list of references for articles that might have inspired this post. There wasn't any direct reference that I was building upon. Most of these ideas come from my observations as a user and now as a builder of these products.
(3) I am not, and would be interested to know more!
Thanks, so after reading over the post, one thing I noticed was how to take a specific category, for example, configurability — and build it out based on real customer demand. While might not be what you meant, one example would be reporting systems that basically let an end user build a report for anything. If you’re asking customers if they want it, frequently they well say yes, but regardless of if they know how to use it, frequently only build fix set of reports and never make adhoc reports. So, not expecting you to answer, but the question is, how do you identify if XYZ request is real, validate it, onboarding for customer success is appropriate, and kill it off correctly if users don’t use it to avoid pilling on tech debt.
Next, actually remember seeing customer feature request trackers and found a few, though have tried to find someone actively managing these in the open: