Being a Lean Product Manager "Product people - Product managers, product designers, UX designers, UX researchers, Business analysts, developers, makers & entrepreneurs 10 July 2012 True Continuous Integration, Lean Product Manager, Minimum Viable, Testing, Tips, Mind the Product Mind the Product Ltd 743 zen garden Product Management 2.972

Being a Lean Product Manager


Zen Garden
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.

Comments 1

Nice article. Lean principles, especially as it applies to requirements gathering, specs and inventory is an area I’m really interested in.

I did think you had one quote which puzzled me a bit. Your quote:

“Being methodical and focused delivers far more faster than being agile and jumping around from point to point.”
Your quote seems to suggest that being methodical and focused is not Agile, whereas I strongly disagree. Agile is designed to allow responsiveness to customer/market demands to better deliver business value, maximize ROI etc etc. That doesn’t mean context switching so quickly that you have no hope of actually ever delivering a feature – hence the two week time boxes that most Agile software dev. frameworks have.

Interested in your thoughts on this, or maybe some clarification on your quote?


Join the community

Sign up for free to share your thoughts