Product Engineering with Nagpur Orange

“Be stubborn on vision but flexible on details” - Jeff Bezos

#productengineering #productdelivery #saasproduct #strategyplanning #cxoreview #productinnovation

People in certain parts of India pride themselves on certain types of Orange which are greenish-orange in color. It is popularly known as Nagpur Orange. These types of fruit are also available in Southern Karnataka - Coorg. The skin is losely attached to the fruit, by lose fibers. Peeling the fruit is very easy. There is a distinct taste of the fruit that makes it popular. The delicious taste would not have been possible without the skin, but still the skin is loosely attached to the fruit. Keeping a little distance between you and the Product would augur well for both, in long term. The little distance would help you to look at the Product with near zero bias. Lets examine few key aspects of Product Engineering

The Nuances..

• Chat with Business - Often, Very Often , Formal & Informal. You will discover their pain areas that would act as a guiding principle in consciously choosing your backlog or creating new User stories
• It pays to be deeply aware of what the product should NOT do. It is a tight rope walk with business who would want everything under the sun, NOW.
• Give them couple of features more than what is asked for. You could find yourself in a spot where there would be nagging, tiny inconveniences / bugs discovered during a feature roll-out. The additional features provided would kind of act as a ‘set-off’ and would calm down the nerves of business
• Learning to push an important unstable feature to the next Release is very important. Nobody likes it, but then - Platform stability is more important than exciting features! However be ready to face the music in short term.

Choice of technology..

Picking up a fresh new technology is compelling and inviting for techies. It brings excitement, plethora of possibilities and new avenues for individual career front. As a Product head - ensure that you validate these, via PoCs. Its worth while investing on couple of PoCs and then make informed decision. Be conscious of the fact that you could be up against the brightest techies who would be in heavy favour of latest tech stack. It is wise to chose a stable version as against a fantastic latest version, that is released few weeks ago!

Product RoadMaps..

A 1 year and a 3 year road map is more important than a 5 year roadmap. RoadMap for the first year is a first step towards the Product vision. Hence it would be an expansion of the first couple of features derived directly from the Product vision. However if you are up against a Product transformation, it would simply be a list of Priority-1 items from the Product backlog. A second year revision becomes equally important - when you visit the Product Roadmap?- you are bound to have a backlog that could not be completed owing to various factors

Take note of what gets used by business and users and provide value adds to those functionality. They must get prioritised and be budgeted in advance!

Keeping the product simple and aligned with the Product vision is a complex work. It pays to keep the clutter out.

Product Schedules and Commercials..

The key is not to prioritise what is there on your schedule, but to schedule your priorities - Steven Covey

Project schedules are better driven by Project Managers(PM) as against a Product Head/ Lead. The PMs are more grounded on the resourcing needs along with the detailed estimates. A Product Lead, must be more aware of T-Shirt sizing estimation along with broad cost estimation. A 20% buffer is desirable in estimation, after taking into account certain licensing aspects of the dependent technology stacks.

Product support and maintenance..

Its very important to be creating a FAQ on the Product. The FAQs typically address most of the basic questions that the users are going to face the first few weeks. As the Product evolves you might uncover functionality related errors that could be fed back to the Product development team

A lean team per geography / time zone might just be sufficient to take support defects and provide bug fixes.?

Enjoy building Products