Why does Phyllo exist

For a business (or developer), Phyllo is the channel for any work related data of creators. This creator work data helps businesses build and deliver better product offerings to their user base of creators. Phyllo is not bound by the means of collecting data and will do anything possible to enable businesses access and use this creator work data.

The means of collecting & sourcing this data can either be open APIs, web crawling, or even visiting the creator's house to check on them. We are entrusted with the "job" of sourcing data for developers, which does not limit us by the means of sourcing this data - as long as it is consensual, compliant, and solving the problem.

While building or designing any product at Phyllo, we pay the utmost priority to creators and their interest. Businesses in the creator economy space maybe our current paying customers but our product experience, build, quality, and decisions should be geared towards creators as they are the true consumers of our offering and would ultimately influence the future of Phyllo's business.

We want creators to utilise their own work data to access products and services that were either out of their reach or were unduly ignored because of the nature of their work.

The Product Manifesto

For anyone in the product team at Phyllo, these are our guiding principles when we set out to build Phyllo.

1. Our customers are both creators and developers. Creators first, and then developers. Always.
2. Deliver a product experience for our customers that is 10x better than what they currently use.
   1. Best: 10x improved experienced
   2. Good: noticeably better than current alternatives
   3. Bare minimum: experience should be greater than the friction involved in using that product.
3. Product execution
   1. Seek out problems. Not all problems may surface up to you.
   2. Validate that the problem indeed exists.
   3. Explore all possible solutions to that problem.
   4. Filter out solutions that do not abide by #1 & #2 of guiding principles.
   5. Pick a solution in consensus with all internal teams that are impacted by this problem & solution.
   6. Build in iterations, that allow for iterative user & internal testing.
   7. Measure what you launch. Fix, if your released changes are not solving the problem.
   8. Engineering bandwidth is your currency. Do not waste it.
4. Process over outcomes
   1. It is OK to fail as long as the right process was chosen for execution.
   2. Retrospect on failure and take corrective measures to avoid repetition.
   3. Obsess over quality. If it caught your eye, it would catch the customers eye too.
5. Our benchmark for quality
   1. If you will not use your own product, neither will your customers. Dogfood what you built.

<aside> ⚠️ Note: These principles are not all encompassing. Processes are always contextual, use your judgement in applying the right solution and process to each problem.

</aside>