From the early days of PeerIndex we’ve been running as a (very) lean startup. This has taught me some lessons about the practice of Product Management in lean startup environments. This is less about the use of customer development tools and finding product market fit but rather about some tips and tricks that made my life easier.
Tip 1: Plan but use Minimum Viable Specs
Don’t write long specs. It is easier within a lean environment to plan large features or functionality but only spec out the minimum necessary to demonstrate the feature and get early feedback about whether people like it or not. This simply saves you time writing long and detailed specs but also allows you to adjust quickly if a feature proves not to work.
An example of this is the Groups function in PeerIndex. The very first release of this feature was very basic to see how people reacted. When everyone reacted positively to it, we then improved the functionality. I already knew what the additional functionality was going to be even if I hadn’t spec’d it out.
It isn’t necessary to build something in order to get the feedback. Paper mockups and fake prototypes can work just as well as an actual feature. It depends on the feature and functionality as to what will work.
Tip 2: Be Available
Be available at all times for the developers to answer questions. One side effect of smaller and less detailed spec’s is there will be questions. You need to be available and respond promptly to those questions otherwise you become the most significant roadblock to the developers.
I attend the stand ups and also on the Skype all day and the developers know they can ask questions at any time.
Tip 3: Know your Developers
Have a good feel for the skills and abilities of the developers and incorporate that when design and spec’ing new features. This will allow you to structure the features and functionality so that it can be delivered by one developer. This becomes very useful when working in a KanBan environment as developers become largely independent of other developers work.
Tip 4: Use Feature Flags
Push for feature flags. Feature flags remove the headache of coordinating engineering releases and marketing releases. It allows the developers to use continuous integration and development leaving you to release the features outside of the engineering cycle.
Prior to using the feature flag approach, we spent quite a bit of time shifting code around to get a feature out without pushing out features that we wanted to release later.
Tip 5: Be Methodical
One disadvantage to lean is lean. It is far too easy to change direction based on little data which leads to having too many things going on and nothing ever completed to a satisfactory state. You as a Product Manager need to understand the basics of population statistics. If you don’t you’ll be forever chasing transient noise because your sample size is too small. It also applies to having many balls in the air at the same time. Time and time again I’ve found that the developers, I and the company have been most productive when we are focused on a particular area or are methodically chewing our way through issues.
Being methodical and focused delivers far more faster than being agile and jumping around from point to point.
Tip 6: Bonus: Testing is a god send
Although I said 5 tips, here is a bonus. Testing. Get automated testing. It is a god send in reducing the amount of long term bug management and the need to rework to fix introduced and regression bugs. The earlier you bring it in the easier it is for everyone despite the fact it will length the time of earlier deliveries. Systems quickly become complex to the point that even simple changes have cascade effects. Automated testing does wonders for shortening the cycle necessary to detect and fix unforeseen results from even simple changes.
In fact, I encourage you to push for continuous integration and automated testing using an arrangement such as GitHub and Jenkins now. It sounds silly as a Product Manager to be pushing for that but you need the development team to be as productive as possible. If they are continually chasing bugs that ain’t going to happen and as systems grow more complex the productivity of the development team will sink like a lead weight as the bugs get harder and harder to find.