In the previous post, I outlined a part of my innovation journey as a software developer creating a new product. To start with, in the first part, I outlined the context. This was followed by the missteps from conceptualization to a point when I created a gold-plated product solution. In this post, I will layout the missteps from a premature scaling of the solution up until a point when my batteries got drained.

Scaling the product, too soon

Apparently, I sold my ideas quite well. Hence within one year, multiple program managers agreed to integrate my solution on their platforms. This was for them to show a working prototype back at HQ. I got a small team to scale the porting of prototypes. Each of these program managers gave me a couple of developers from their team. Two members of my team worked with them to port the solution on these multiple platforms. I proposed the very first UX we had conceptualized in the early days, helping the teams write the abstraction layers. Rather quickly, we were ready to demonstrate more prototypes.

In retrospect: I tested the waters with people management. Inspiring & coaching members of the team to innovate. However, taking too many prototyping efforts simultaneously, was the biggest misjudgment here. More so because it limited the ability to learn from each effort. It constrained our ability to apply the learning from one assignment into the next one. Saying NO was important at this stage. We practically became a factory, porting the prototype from one platform to another. If we had, at the beginning, defined the parameters to measure success, we would have known when to stop.

Reducing 3rd party dependency

At this point, we were still dependent on the device capabilities on different platforms. Understanding those layers, and then filling in the abstraction layer took most of the small-time needed. I thought “Let’s get rid of this dependency”. So, collaborating with some other R&D teams in the organization, I pre-integrated some software components into the solution. We had thus drastically reduced dependency on third-party platforms. Thereby potentially reduced the time to create commercial-grade software.

In retrospect: This is akin to solving a non-existent problem. The collaboration across the organization, helped build a network and know what others are doing. But the effort spent on preparing for a far future possibility was unwarranted.

Throwing in a 3D effect, adding cool stuff to the product

At this point, there was a team experimenting with OpenGL on smartphones. Working with some of those experts, we created a cool 3D visualization of our idea on the smartphone. We even made demonstration software for CES, Vegas! Ready for #WorldDomination!

In retrospect: Was this really needed? Did it take away our focus? Why did we engage in it? OpenGL and cool-factor with 3D had blind-sighted the focus of our product. It would have been good to validate the user experience with this new feature. What did we learn from our experience with the 2D solution? Validating the user need, the interaction design and testing it with real-users was missing.

Still not a commercially shipped product!

Despite all this effort, up until that point, we didn’t manage to move the needle on any of the platforms from a ‘proof-of-concept’ to a ‘commercial-solution’. I relentlessly persevered to take this through but didn’t succeed. Exhausted & disappointed, I eventually moved on to other ideas and then onto another team within the organization to get onto another journey.  

In retrospect: While in my mind, I had failed to commercialize this, I was unwilling to acknowledge the truth. Ideally, I should have engaged with the rest of team, the developers in my team, my manager and the other ‘prototyping stakeholders’ to dig deeper. Ask the five whys. Find out what went wrong. What biases were in play? Was there a problem to solve? Or were we too solution-centric? Were we organized correctly? Did we have a self sufficient team? And more…

Wrapping up

Clarifying the goal, the key success factors and the desired impact was important. Asking what value will be created and captured would have helped shortlist the ideas better. Taking user experience for granted was the biggest mistake (A phone in our palm and a TV on the wall are two different experiences). Further on, not engaging in user testing, not validating prototypes and gold plating the solution prematurely was like taking the wrong direction on a highway. Prioritizing learning from the first few prototyping, rather than the full-scale prototyping on multiple platforms would have helped. Not losing focus on the objective and diverting time on cool features and addressing non-issues took away energy. And lastly, closing this assignment with a healthy mix of stakeholders to do a retrospective would have been a brilliant idea!

I would have done all of that if only I had the Product Manager mindset back then …

1 Comment

  1. Pingback: Don't build a product like this! (1/2) - Shubham BHATTACHARYA

Leave a comment

Your email address will not be published. Required fields are marked *