Category: Product Management

Mid-journey designer

About a week ago, good friend and head of design (of a leading edtech company), Hardik Pandya, advertised a position (on x/twitter) for a designer who needs to be comfortable using midjourney for design work for a new product.

This (quite obviously) got a lot of eyeballs and opinions – basically did what it was supposed to do.

At the root of this, this essentially validates something that I have been saying for a while. This whole generative AI thing (and I am not generalizing AI for this) is something that is going to enhance the productivity of specialists. Sure some mid level people who are either not competent enough or are not adapting fast enough might get affected. But the general rule of thumb is – if you are adapting yourself to latest tools, you should be fine. This is something that you should have anyway been doing all the while.

Let us take the example of designers in this specific context of the tweet.

  • A good designer’s competency is his way of framing a UI screen / graphic. The way the colour palette is chosen. The way copy enhances the visual. The gradients. The user interactions. The way by which you lead the users’ attention/flow. Once the designer has this nailed (or has the capability to iterate to nail), then its a question of using the right tool for the job.
  • A good designer has probably anyway evolved throughout their career – from photoshop to sketch to figma. This is based on my exposure to the tool chain for a limited use-case superset that I have been involved in. I am sure there are other tool chain evolutions that others can quote.
  • The latest is evolving to a way by which the designer describes all of the above by way of a good prompt. Most likely, the designer would get a 80% accurate outcome (or some similar high percentage), and then the designer iterates on a tool of choice to get the final outcome.
  • The better the designer is with generating the prompt, the quicker (and lesser number of iterations) they get to a high fidelity outcome close to the final. By the time, they are extremely efficient, they are probably close to 95% accurate through their prompting and just have to add finishing touches outside of genAI.
  • Do you see the parallel with extremely competent high productivity PMs <> designers combos?
  • If not, I will give you an example. At Travenues (early stage small team size startup), when I used to sit down with Das (Abhisek Das), our designer with whom I have worked with in the past, and work on a screen/graphic. I would keep rattling off my product thoughts, and Das’s hands flew on figma. It was magic watching the design come alive in front of me, as I iterated, gave feedback, gave more product thoughts, and it just evolved.
  • The expertise power shifts right with genAI. If the designer learns how to translate my PM thoughts into a design prompt, imagine the rate of productivity improvement.
  • Also, do notice here, that the designer cannot be replaced with the PM. The designer knows how to prompt way better, because he has the outcome in his mind, and he is getting the machine to churn that out as closely as possible to what he has in his mind.
  • The designers competency in this grows as he does this more and more (and the models become better and better).

Out of several fields getting impacted with GenAI, this is one of those where I can see first hand (in my mind and in real life recently), how this can practically increase productivity significantly. (The other one is of course code generation, which I am not that close to, but I see very similar parallels).

Keep them busy!

I spoke about this in a recent 1-1 and I thought I would pen this here. (Used to do this quite often early and want to restart doing it).

This is in context to being a PM in a large scale company but with appropriate modifications, I feel it works everywhere.

We were talking about focus time. In a large company, there is always a sense of being busy. You might be accountable for making triaging decisions, attending stand-up meetings, aligning stakeholders, prep-ing for exec presentations, among many other things that you are thrown into, on a day to day , hour to hour basis. So, how then, do you carve out time for focus work?

One of the many ways that I have seen work (and I tell my team to do so as well) is to keep your important stakeholders busy. In the case of my team, it is the dev team (and the dev lead). I have nothing against them (or any stakeholder for that matter) ; but it is usually an unwritten rule that devs look up to the PM for anything that they may need help on / get blocked on. So, if you time it and keep them busy during the time when you want to do focus work (say write a deep spec, or analyze competition, or do some data work), you tend to not be interrupted.

How do you do this?

  1. Ensure that the stakeholders have everything that they need for the current project at hand.
  2. Have a ready ‘to-analyze’ list – that you can toss at a dev(s) to go do some effort estimate / tshirt sizing
  3. Send the stakeholders a pre-read of a document that is being worked on with an explicit ask to drop comments (and a follow up meeting to discuss)

The main thing, however is not the external interrupts, during when you are in the zone. It is your internal interrupts, which I also crudely called guilt-checks. Did I give everything that is needed for the designer? Should I give more context to the team? Is there anything due from me for the exec-preso? For this, you basically ensure that you write down a guilt-check list and make sure you are convinced that everything is taken care of.

This blog post (like many others in my blog) is mostly a top of mind dump. What do you think about this problem? Do you have a process to get into the zone? Comment / reply / or engage on twitter (@gcmouli).

Communication …

Communication (n) – a process by which information is exchanged between individuals through a common system of symbols, signs, or behavior.

During this very difficult time of the entire world fighting the CoVid-19 virus, companies have been forced into this new normal – a way of getting things done through entirely remote teams, connected virtually through mediums such as Google Meet/Zoom (meetings), Slack / MS Teams (asynchronous communications), and of course good old Email.

In this blog, I will attempt to condense my decade or so of learning to communicate properly. These are years of communicating with geographically dispersed teams across three continents, with teams that worked on strong waterfall models, with teams that have been extremely agile and dynamic, with cross-functional teams (business vs tech vs product), with teams that were amicable vs hostile ; you get the gist. Disclaimer – This subject is huge, and I am still learning.

Up until now, good/great communication has been seen as a productivity booster ; but now, with this new norm, it is a necessity ; and can potentially do harm if not done properly.

Just to recap, the advantages of good communication remains the same as always:

  1. Unambiguously transmission of information
  2. Get alignment
  3. Take quick decisions
  4. Reduce communication strain (reduce unnecessary back-and-forth flow of information)

And lets dive into the thick of it. These are points that are in no particular order (of importance or otherwise).

Email: 

  1. There is not a more trite advice than writing concise short emails ; but people still do not follow it.
  2. Subject line should always say exactly what the email contains. This is the first level of mind filter. Use it to your advantage. If it is important, use tags such as [Important], [Blocked], [Need Your Approval] etc to identify actionable emails.
  3. Start the email always with a sentence on what this email is about. Most people will choose to read the email or not or park for later depending on this.
  4. In this first sentence, always ensure you are setting the expectation for the reader on what she will get out of this email. Use phrases such as ‘short list’, ‘summary of..’, ‘detailed explanation of ..’.
  5. Use bullet points thereafter. The human brain processes this much better. Seeing three bullets (with explanations if required) gives the user a sense of quantifiable effort required to read/process the email – than three paragraphs (which will 90% get skipped).
  6. Last sentence – always summarize. Highlight or bold or identify with [Summary]. The hurried email reader will be super happy.

Slack:

  1. Use the right channels. Tag the right people appropriately.
  2. Decide when to write on channel and tag someone or DM someone directly. Its important. If the Signal-to-Noice ratio becomes unmanageable, focus workers such as developers and designers will inevitably mute the channel.
  3. Use @channel very sparingly – only for appreciations and announcements
  4. If you are a leader, and you are going to be doing this often, have a separate channel for the same.
  5. Have a separate channel for fun and banter.
  6. Decide early whether you want to have project based channels (#new-design-revamp, #add-apple-wallet, #loyalty) or any other way of identifying channels (#android, #ios, #frontend, #ui, #design)
  7. Use threads to your advantage. Keeps the channel clean.
  8. Use the ‘Sent to Channel’ also option sparingly. It is always confusing to see the same thing in two places. Reserve it for important information that you want to surface to the entire channel.

Zoom / Hangouts / Phone:

  1. Always set context on email / invite. Always repeat context in the first 2 minutes of the call (if you are leading the call).
  2. If there is a decision that needs to be taken in a meeting, there has to be someone who will continuously need to be on the look-out that, the conversation steers in that direction.
  3. If it is a catch-up call, that one person needs to ensure that, there is equal mic-time for everyone.
  4. For detailed discussions, Amazon’s written spec method or a separate presentation-followed-by-discussion is the best. We should all accept reality that not all discussions can be done in a status/catch-up meeting. Relevant folks have to get back together virtually and do it separately.
  5. Short focused meetings help attendees feel that meetings are not a waste of time. A few vague meetings are enough to change this perception. As a leader or yet another meeting attendee, let us do each of our bit to ensure that this does not happen. (This is also called meeting fatigue).
  6. For important meetings. one person should always take down notes.
  7. Brainstorming sessions are a different beast, which I will blog about later, as a separate post.

Hope this free rambling set of communication learnings help. Will try and write more on these in the days to come.


Two Controversial PM objectives

(img src – taken by me – Shotang Demo Day)

There are two slightly controversial topics that I hold dear to me, when I think of PM-ing.

(1) Stake holder management – internal and external. I have written about this extensively in the past. Some folks think that it is a project/program managers job. But I don’t. I think it is an integral part of a product managers job. No one knows the bigger picture and the granular details of the product than a PM. Getting every contributor and decision maker in the same page is super critical. Giving this job to a project manager is suicide. Absolutely lack of credibility will kill everything in sight. (I have nothing against project managers, but they are ninjas at managing the project as an entity, and not quite objectives and people).

(2) Data is everything in this new world. But ever so often, there is either too little data, or there is too much data. In both of these cases, it becomes incredibly hard to extricate inferences out of the data, leave alone insights. During these cases, it is the singular responsibility of the PM to work closely with leadership to suggest a solution based on “gut feel”. The extensive involvement of the PM in the multiple facets of developing the product (no one else puts their fingers into so many facets as the PMs) makes the ‘gut feel’ more credible.

Mobile Jewellery Shop – Lalithaa

Disclaimer: Most of what I talk about below – are my observations from Southern parts of India, and might not be applicable to Northern parts, which I am not very familiar with.

Lalithaa Jewellery seems to have introduced a mobile jewellery shop in the form of a modified long chassis bus. I think this is a darned good innovation. There used to be a time when the predominant way of doing jewellery was to go to a jewellers shop, where you discuss patterns, weight, wastage etc, and then the jeweller would custom make it for you.

Some of these jewellers in Tier 1 towns (such as NAC etc), who had access to capital and fast business movement, had ‘some’ ‘readymade’ stuff – things such as small silver tumblers, chains, rings etc – which are mostly impulse buys. In recent times, large box format stores (mostly chains which have large capital) have started making their presence (Malabar, Jos Alukas etc). These stores started off in Tier 1 cities, and now started slowly moving towards Tier 2 towns as well. Accessibility to ‘readymade jewels’ is significantly improved because of this. A ‘trip to the city’ is usually saved.

While accessibility is improved, it is not economical for these large format stores to go to every Tier2 and Tier3 towns. I think this is the market that Lalithaa is targeting. For some context, Lalithaa is one of those hybrid stores, which does some custom jewellery, but has predominantly large inventory of pre-made jewels. This bus looks to be a modified shell with a proper jewellery shop facade, counters, staff etc inside. The bus is now stationed in Theni (a Tier 2 town in the border of TN and Kerala), in a fair ground.

These large box stores do a ton of advertising on main stream cable/satellite TV – whose penetration in India has just exponentially risen in the last decade (next only to telecom). With the brand visibility already present, with the store coming to you, I think it is a novel technique to increase the reach.

Couple of feature-y things that come to mind –

a) Some rough schedule of the bus (perhaps a loop), so that folks in towns know when the next bus would be here next. Maybe even a call center or recorded info about the bus whereabouts.

b) Some form of demand capture – phone perhaps, (and in the long run through learning from data).

If this is successful (or not), I see this as a model that should be tried across other verticals too. Very interesting. #SolveForBharath

Empathy and PMs

http://coachfogs.blogspot.in/

I have been thinking about this word for quite a bit of time these days. Whenever I am talking to folks and describing my definition of being a Product Manager – almost every trait distills down to this one word – Empathy.

Now, let me try and recollect and jot them down here –

  1. Stakeholder management – One of the key traits that I believe a PM should have. The cliche’ phrase of PM being the CEO of a product, imho loosely translates to this. Unless you are empathetic to the various parties (product, tech, marketing, operations, leadership, …), you will not be able to get them on to the same page. You need to empathetic to the tech team as to why they are resisting a decision ~ perhaps this would involve tossing out a lot of code that they just wrote; you need to understand how they feel. You need to be empathetic to the operations team ~ perhaps they are short staffed during a certain time and they cannot handle so many escalations. You need to feel this issue. And so on.
  2. Customer empathy – this is a given. A PM should be the biggest voice of the customer within the company. This might be a bit contrary to the first point, but customer empathy trumps empathy within the teams. You do not care if code needs to be rewritten, or more support staff needs to be hired, but if the customer experience is affected, it is unacceptable.
  3. Strategy Roadmapping  – this is empathy at a different plane. A product leader needs to sense the emotions of the founding/executive team and the investors (if any), to see what would deliver the best RoI for these stakeholders. Too aggressive a roadmap might seem awesome to the investors, but not to the leadership team, but too sluggish a roadmap might make the investors lose confidence. This is extremely important. This is in most cases unspoken and very subtle.
  4. Project Management – lets face it. This is a part of a Product Managers job ~ in varying degrees depending on the org. Good PMs exhibit a bias towards action(shipping) and make a dent here. While strategy/road-mapping is part of steering the ship, project management is choreographing the drum-beat of releases. You cannot do either of these without a deep sense of empathy to the executors.

And for those who are wondering if empathy is a key trait only for PMs, nope, check out Rand Fishkin’s blog where he says –

The best skill I’ve developed and the one that’s served me best as a founder, a CEO, and a marketer is empathy.

I offer coaching/training on PM empathy. If interested, please ping me on gcmouli at gmail.

 

Small data

We keep hearing about Big data everywhere – sometimes in places where we do not even expect to here it. I was listening to the latest Trailblazers podcast from Walter Isaacson, and he just casually dropped this nugget.

Small data is the capturing of the small, subtle nuances of a customer. A lot of times, these small seemingly insignificant subtle pieces of information lead to huge product insights.

While extracting big data, and distilling data out of it is important – it is still generalisation. It is amortised data. It is a collective. It is very important for PMs to observe customers at close quarters on a regular basis.

In my three years of observation, being a product leader, I have seen that insights distilled from big data, can only result in incremental improvements.

To get 10X improvements, we need to observe and incorporate these behavioural, often times visual, subtle insights. These are few in number – viz small data.

Decisions, decisions, decisions …

Much has been written about the functions of a Product Manager (PM). I usually do not subscribe to the ‘textbook’ definition of a ‘mini-CEO’ of a product/feature. I feel that, while there are a few overlaps between the roles, it is unfair for the CEO and for the PM to be called the ‘mini-me’ of the other.

One of the overlaps that I find very interesting is that of decision making. For a PM, and more so, for a PM leader, this is one of the key attributes. In fact, as you rise up the ranks of PM-ship, more and more of your tangible time would be going towards decision-making.

There are a few things that I wanted to talk about in this post, about decision making – in no particular order.

  • A lot of times, you would have enough data that you can lean upon, to make a decision. Why do I say ‘lean upon’? If the decision is perfect, then kudos, but then human tendency is to fall back on the data as a crutch, when the decision is wrong. The key thing in the latter scenario, is to learn from it. There is nothing more you can do from it. Accept that, data, can sometime fail you, and try and find a pattern that you can recognize in the future.
  • There are definitely times, when you would not have enough data. In a subset of these times, you also do not have the luxury of waiting for data to be got/collected. In these cases, a seasoned PM would need to take decisions based on extrapolating whatever data she has, or to be able to correlate with an analogous event/incident/feature/project and take a gut call. The key thing here, is to stick by the decision, immaterial of its outcome. Human tendency is to exhibit ‘excusitis’. Like in the previous point, learning is key.
  • There are three typical classes of decisions that PMs make on a regular basis – assumptions/trade-offs ; prioritization/road-map ; go/no-go.
    • Assumptions and trade-offs occur during mostly the planning phase. During the planning phase, the PM, along with business, and the tech-lead, need to freeze on assumptions/trade-offs to be able to ship within a certain deadline, or be able to ship with constrained resources. Resources, here, can be team, compute resources, or technology stack. These decisions sometime creep in during the execution phase – typically due to late realizations or plan changes etc. The PM’s negotiation and influencing skills also play a key role here, along with the decision making skills. Example – Given that a new feature would be hand-held by the feet-on-street teams, the first version of the feature need not have as many educational prompts.
    • Many think that prioritization and road-map decisions occur during planned times (month/quarter beginnings etc). It definitely is not. The best PMs are continuously prioritizing. Devs get sick. Servers go down. Unexpected bugs turn up. Features get new requirements. In an agile environment, a PM needs to manage all of this, and still be able to ship reasonably on time, with adequate communication to all stakeholders. New ideas do not wait for quarter beginnings to pop-up. As and when they pop-up, PMs prioritize and add to the road-map. Again, a continuous process. Example – The biggest issue is to identify if IMEI numbers of returned products match the ones in our system. Let us build a first version that will let the call-center support team do just that. Further versions can be fancier and accept direct requests.
    • Lastly, a go/no-go decision. This is when a PM works closely with QA and business teams to decide, whether a feature can go live (or not!). Time pressures and business requirements often require a feature to be shipped at a certain date/time. A lot of times, this is non-negotiable. However, a PM can take a call to go live, with a version that probably has a non-show-stopper bug. Breaking design perfection paralysis also falls into this bucket. Example – When the seller does not have stock of products, and he is prompted to give multi-tier pricing, the UI might break. Ship the feature, and fix the corner case UI in a subsequent merge.

I have not counted hiring decisions in the above list. PM leaders would need to make hire/no-hire decisions for hiring PMs in their teams. In some companies, PMs are also called up on to do an interview round for senior dev leads and designers.

PMs – have I missed anything? Let me know in the comments below. Would also love to hear examples of key decision making techniques that you follow.

Modiji, Bullet trains, and the Prioritization conundrum

PM Modi and the Japanese PM Abe jointly laid the foundation stone for the first bullet train in India. Enough has been ranted about this in social media. About, why this is not the thing that is needed now. And why the Govt should fix all the issues that is plaguing the railways and so on.

I think this is a problem that Product managers face too (Hmm. Just a coincidence that, they are PMs too.).

The feature prioritization conundrum is the scenario where a PM is faced with a host of small urgent + Important  issues/features to deliver in a short time-frame ; and a smaller bunch of longish important but more challenging hard problems to solve. The engineers want to do the latter, but the former are very important too.

A PM cannot keep prioritizing the smallish important problems higher, because they will never end. You will never get to the largish challenging problems. This will lead to your engineers getting demotivated and doing mundane familiar stuff. But at the same time, you cannot just prioritize the challenging projects – this will keep your engineers happy – but the business suffers. Some of these urgent+important tasks are most likely important for the business.

One of the solutions to this is to assign more than one task to engineers. This should be a mix of the smaller urgent tasks and the longish exciting tasks. This will keep your engineers happy and the business going.

So, does that make, what our Prime Minister did, with the bullet train right? I do not know, since I do not have enough context. But if I see the PM as a PM ( 🙂 ), then I guess he is doing the right thing.

What are we shipping today?

Ask any of the PMs who have worked with me, they will say that this is my favourite statement. I ask this statement at least once a day to them.

I was talking about this with one of the PMs who works with me, and I thought I would share some of the conversation highlights here.

  • Shipping is the most important outcome that any PM needs to aspire towards, at any given time. The more you ship, the better you are.
  • The primary reason for existence for a PM (in my humble opinion) is to ship. Sure, programmers code. Designers make the product beautiful and usable. Business folks give their requirements. Marketing folks get out the word. Customer support teams are on standby. But what is the use of all of this, if you do not ship. The PM is the glue that enables all of this to come together and ‘happen’.
  • Example of ‘shipping’ being considered a real (and an important) thing — the famous ship-it awards in Microsoft. Every stakeholder who was part of a release used to get a Ship-it award (a tiny trophy kind of thingie). MS folks proudly display these ship-it awards on their desks.
  • A lot of PMs that I know (including yours truly) come into this field from Engineering, Marketing, and various other fields. In most cases, we have boarded this ship, as a leap of faith. As a matter of fact, the best PMs are the ones who learnt on the go. It is incredibly hard to ‘explain’ to someone, or to ‘teach’ someone about ‘PM-ship’ (no puns intended). In these cases, the only way to ward off self-doubt (which is bound to happen) whether you did the right thing — is to ship. You keep shipping. And the spiral is always upward.
  • Shipping creates tangible outcomes. And it reinforces.
  • Ship incrementally. If this is not an option, get your devs to at least commit incrementally.
  • Lastly, you are known by what you ship.

The original conversation was a very free-wheeling conversation during our 1-1. And so, was this recollection of thoughts. The above is in no particular order.

 

(Cover image source)