Throughout the course of building our side project, my co-creator and I had been looking for ways to balance codebase construction with marketing outreach. This was a problem as our production deadlines would fluctuate which would then mess up our dialogue with potential users.
We needed a more formalized "map" to guide how to reach out to leads so that our message would be consistent and coordinated but we also didn't want the arbitrary project-based "deadlines" to dictate our organic hacking. So the two of us sat down and discussed how to best tackle this issue - this is how we came to what we've dubbed "code-driven business development."
This approach centers on two principles:
- self-awareness: thorough feature/project outlines and stated goals
- user-awareness: identifying level of user interest/participation
These can be formalized into specific action items outlined below:
- sort all leads/users into alpha/beta/production categories based on the product release level they are interested in participating in (e.g. user A is interested in beta releases)
- outline specific requirement items needed for each release level of each feature prior to beginning construction (e.g. beta needs a functioning UI)
- update/track progress on the requirement items as progress is made building the feature into the codebase adjusting the list if needed (e.g. functioning UI is complete)
- contact leads/users when their respective release categories are reached as requirements are completed (e.g. "Hey user A, the beta feature is ready!")
The above release categories could be loosely defined as such:
- alpha: product with missing features and potential/known bugs
- beta: product with more/all features and potential/known bugs
- release: product with all features and no known bugs
We discovered that this approach achieves a couple interesting things.
First, it requires that the project creators engage in active communication with the end users. This is because they need to define the release comfort level for the lead/user but it also allows for opportunities to identify desired features or pain points within the product. On the builders' side, it really lets the developers focus on coding. When tracking requirement item progress, the developers would have an immediate picture of the current business development state while also delivering exactly what each client expects in their respective release.
Overall, this approach is definitely a work in progress, and we'll most likely be tweaking it going forward, but I like what we've settled on so far.
Let me know what you think!
P.S. If this exact approach exists somewhere and I totally overlooked it, please point me in that direction.