March 18, 2024

The times are changing in product role

Navigating the art and science of product development through real-time learnings, constraints, and theory building.

Product Functions

If any of you happen to meet me or talk to me in the recent past. I would be emanating a sense of calm. This is the exterior cover that is going through a tumultuous journey of learning the art of product while building it with more scientific rigour.

Whenever such times come upon I start sharing my learnings in public in the form of snippets. If you excuse the grammar and spelling mistakes(which you do in this newsletter as well), it comprises of the lessons learnt in real time. Last months were filled with some steep slopes on the learning curve of product building.

In addition to this my track record of constantly searching to change things up doesn’t help for being calm. In this Calvin Hobbes comic strip you the get the basic drift of battle that ensues in my head.

I volunteer to make change by not changing how I operate. It has its plusses and minuses.

Ultimately, during the process I gain information which is distilled into knowledge through writing of some sort.

Unlike Calvin here who is aiming for an opposite goal post, I write things down to think but it gets shaped to behave well.

The building part of product has been my focus for past year but going forward I wanted to focus on positioning, sales and onboarding as well. This dawned on me because the capabilities and adoption gap are evident and needs work to be done. Presenting them with some more context.

All stages of product growth permeate from a sense of narrative building which show up in positioning and sales pitches. They are pivoted to problem being addressed but the obvious nature of “why this works” only comes from the arts side of product building. Source

The division of product into art and science came through once I started to grasp the core facets of a growing product and understanding how it impacts the customers.

Product development is equal parts arts and science. The rubric of it being a function of prioritisation comes from the inherent bias that the things to come next is obvious while building a product.

Product development in legacy domains is similar to running a change initiative. The basic process of taking a service design approach where the end product plays a part becomes enormous help in articulating both the context and leverage points where we could act.

The unsexy part of product building is onboarding a customer and it doesn’t start with the sale. It starts with making the customer aware of problem with the status quo. Source

Legacy domains are equipped to maintain status quo. The process of running them is complicated, making them inadequate to the changing world or enhancements that could help people working with these processes become more productive as well. It helps to treat the domain as a map and processes as challenges you surmount when you play a game. The analogy of gameplay fits well in defining the customer’s journey with your business.

The analogous nature to developing a game becomes evident once expertise is formed in the domain where your product operates.

If you can define the type of game, the mode of gameplay and gaming experience that is feasible as an organisation. Things like finding product marketfit, positioning and sales pitch all become obvious when you refer the examples of how games are marketed in this day and age. Source

Building a product involves constraints from either market, development or capital. Instead of considering them as bottlenecks, we should incorporate such constraints into how we develop the product.

Making minimal changes to the backend schema helps in accruing process knowledge and compound the pace of experimentation that one could achieve it incremental product building.

The innovation in product development stems from the constraints you apply to your backend schema.

The number of times you change your backend are the number of time you begin again.

And if you have to change, remember the lessons from the past iteration Source

Round up

Sources that I have put to practice

Design is how it works

I happen to re-read this post by Jonah Mcintire while preparing for a presentation at work. To be honest, I understood the premise of the article when I read it the first time but didn’t give it the prominence it deserves.

For the better part of last 4 months, I have been exercising the act of manifesting a theory into our product.

The key attributes of a theory are listed as follows and then the translation of this to product.

There are a few key points I’d like to draw attention to.   1. While continuous refinement does happen, real progress is infrequent, abrupt, and transformational 2. Scientific truth is in part a collective agreement among domain participants. 3. Competing theories are difficult (or perhaps just pointless) to compare in their own terms. I think these points are incredibly germane to theory building for software products. Let’s start with the paradigm shift aspect. Successful products create discontinuities in their markets. Your phone's SMS didn’t get better a bit at a time until it was free to use around the world and could handle GIFs, videos, group chats, and provide real-time location pings. WhatsApp did those things.

A theory provides the necessary articulation for explaining domain. Great products come from understanding the context deeply and taking a contrarian approach.

I think great software products will have the following path. First, they are contrarian in a specific way. Second, their contrarian act (as manifested in the product) is insightful. It offers a perspective on “the job to be done” such that, if you agree with the contrarian view, the world is better or clearer in some meaningful way. Third, the world converges to this view via meaningful contact: it begins contrarian but ends as orthodox, and the transition happens naturally as the product’s perspective infects and converts the users. Good products win the argument with the world of customer expectations in which they began as the contrarian outsider. In product management we call this milestone “product market fit”.

This articles ties why design and context happen to be critical components for product building. Product frameworks are templates we use to implement the design and present the context. Using them doesn’t give you the theory. They are similar to templates available in your presentation tool.

Hà Phan, a principal designer at Zillow conveys the same message in a single tweet.

“How it looks” is just a part of “How it works.” How it works is utility.

— Hà Phan (@hpdailyrant)March 15, 2024

Hà is a great account to follow when it comes to research, UX and product nuggets are deeply insightful and practices the same form of distilling the learnings when going to steep learning phases.

Links that resonated

Make better documents

The most common failure cases I see in these kinds of situations is people starting from deep within their own heads, either because they've been fully immersed in a particular project, or because they're reacting to their own fears or concerns

My documents have faced a similar problem in the past. It comes with trying to display everything that we went through in order to arrive to a conclusion. It confuses the reader overall and this was cemented to me in recent feedback session which I mentioned in the last issue.

Steep curves

The focus of learning plays dividends in helping one articulate the direction one needs to make in terms of progress they would like to see.

The brief act of distilling the learning into succinct tweets/twoots/posts is exercise of building in public.

Signing off till next time,

Vivek, reading Calvin and Hobbes to keep calm