Purposely Delaying Features
In a previous life I was a penetration tester. Companies hire penetration testers to break into their computer systems by finding flaws and exploiting them. At the end of the engagement the penetration tester presents the company with a report or a deliverable.
While the engagement is being conducted, the penetration tester sends status updates to the main contact at the company. This status report is the vulnerabilities that were found that day.
The engagements were typically 5 days. The first day of the engagement you would find and successfully exploit 15 vulnerabilities. By the last few days of the engagements you may find a few, or you may find none.
Reporting Nothing Is A Problem
When dealing with Enterprise 500 customers, the expectation is that you are finding something every day. Due to the way penetration testing works, we would find low-hanging fruit as fast as possible to give an excess of vulnerabilities on hand.
We did this in order to spend time on vulnerabilities in business logic, that take more time to exploit. We would refer to this as back-pocketing.
This became a critical mindset to have. When you have days where you haven’t identified new, you had something to present as new.
Taking This Approach to Product
When rolling over to the product side, I took many of these lessons with me. At every company I have worked on product, we constantly work on features, push code, work on bug fixes, push more code, develop a “wouldn’t it be cool if” feature, push new code.
Most of these code pushes are never reported or announced to the customer. They are just pushed and maybe a few observant customers will notice.
When turning to marketing, my team is always working on a “big feature” that will be big news to our customers. A question I often ask is, “How much longer until the next feature will be implemented?” or “How long till the next big thing?”
When the feature is developed, it is “back-pocketed.” Then we market the previous feature that we released, not the new one we have developed.
This does two things:
- It gives us time to bake the feature and identify and fix bugs.
- If the next feature we work on takes “too” long, we can release the feature we have “back-pocketed.”
Here is an example work flow: Develop feature A and develop feature B.
Release one and talk about it. Now develop feature C. When feature C is feature complete, figure out which feature to launch, feature C or feature A. Hopefully it is feature A, because that was previously asked for.
Breaking the Work Flow
I have occasionally broken the work flow above to get certain critical items resolved. I use this as a general approach, but results may vary. I am sure this can be applied to other things other than product management and penetration testing.
I would love to hear any success and/or failure stories where you have attempted to use this work flow in some other area.