It was 2006. Working as a software developer in India, I developed software products for mobile devices. Yet I had never interacted with a Product Manager. In fact, I didn’t even know that such a role existed. I was on a journey of innovation to achieve #WorldDomination.
Here’s one such experience with innovation. There were so many things I shouldn’t have done! I split this post into two parts. In the first part, I outline the context and the journey to creating the first solution. The following part lays out the missteps in scaling prematurely. Looking back now, I wish I was a product manager then!

The context – “How do I …?”

Before iPhones existed, smartphones were just “smart” phones and Nokia led this market. However, we had mastered the art of introducing new phones quickly. In fact, we had a few great flagship smartphone products based on our in-house platform. We were diversified into several platforms including Linux, Windows CE, Android, Symbian, and others. The organization was continually pushing for innovative ideas! Consumers had already started recording and watching videos using these devices. Hence, as an innovation team, we were given one objective, elevating the multimedia-experience of our end-users. From this, started my search for ‘what can I do to improve the video viewing experience of my users?’

In retrospect: Having an objective was a great starting point. But, diving deeper into the objective would have been a good next step. What kind of metric did we want to move with these ideas? Drive up sales, increase brand loyalty, reduce costs, or something else?

Eureka! Hacking a product prototype

The first inspiration came from a living room experience. DVD players at home had some cool features. For example, in some DVDs, the publishers split the movies into ‘chapters’. Users could jump to a chapter directly and resume playback from somewhere in the middle. I thought, “Why not include these in the movie-playback experience on the phone?” 
So I put together an ugly yet working prototype by hacking into the video player engine. My bosses loved the demonstration. However, before presenting this to the department-heads, we decided to beef up the aesthetics.

In retrospect: The job-to-be-done was entertaining (and this scope can really vary!). But did the convenience of jumping across chapters add any value to the lean-forward smartphone interaction? The ideal step forward should have been to STEP OUTSIDE THE BUILDING talking to at least five users. We should have explored the challenges users have in watching videos on these phones? This would have given us several insights and allowed us to dig deeper. Instead, we rushed into framing a solution.

First “real” product prototype

My manager assigned an expert UI developer to work with me. Together, we designed a (2×2) grid interface showing four videos. In each part of the grid, we had a few repetitively playing frames of video. I hoped that this would allow users to navigate across a long list of video. During the process, I created patents for accomplishing the underlying logic. Obviously, I was proud and over the moon!

My hypothesis was that this would help users make quick choices. I assumed that it would help users pick the video they’d like to play from their library. So, after designing the solution, we asked some users for feedback on UI navigation and their experience. On achieving an acceptable quality level, I demonstrated this to middle management. They appreciated and applauded our work. As a result, I demonstrated this solution at almost every ‘innovation-day’ kind of event in the company. 

In retrospect: Validating the user problem should have been step zero in helping to establish a baseline! However, the target audience I asked feedback were fellow developers. Instead, I should have reached out to an ideal audience for the user testing. Developing ‘fake-prototypes’ or user flows would have been a quicker alternative to validate the direction for the solution.

Mission “platform agnostic”. First ‘real portable product solution’

My addressable market was huge! I had to convince the different program managers to integrate the solution into their smartphone platforms. How would I integrate this onto so many platforms? I re-factored the code to be platform-agnostic before creating the first commercial-grade solution. After re-designing the API layers, I could accommodate a variety of UI frameworks. I then geeked out on function-pointers (A C-language programming thing). I created an interface plugging in different types of underlying multimedia engines. All of this was an amazing learning experience. I was now ready to port on any platform.

In retrospect: I should have stopped here resisting the temptation to scale too early. Rather, testing & iterating a first launch should have been the priority. The focus should have been to validate the need and the concept. Ask more questions. What problem am I solving? Is it worth solving the problem? Does the solution solve the problem well enough? Instead, I got hung-up on gold-plating the solution.

Wrapping up part I

Applying the things I learned over the years as a Product Manager, there are several things I would do differently in retrospect. As a result, I gained a lot of humility from the experience. The final part in the next post shows a few more missteps. From how I accelerated scaling this solution to prematurely draining my batteries.