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).

How to choose your co-working space

img src: wikipedia

Context – I had never worked in a co-working space until about a year ago. Made some mistakes, moved, made some mistakes, and moved again. So I guess I want to pass on these learnings to others who might end up in the same scenario.

  • Washrooms. Sounds gross/crude – but take a team member of either sex to go inspect. And inspect once more (another day) towards the evening. Will give you an idea of how frequent they clean.
  • Washrooms are non-negotiable. If they stink one day, do not dismiss it as – perhaps just that day it is stinking (community managers might tell you that). If it stinks even one day, run away. Shows the seriousness of the management.
  • Community Managers. Talk to them. Chat up with them. They are usually friendly. Ask how long they have been there. How much autonomy they get in running the center <– this is very important. Observe how they give a tour. The prouder they show you stuff, the more ownership.
  • Common Area. Ensure you ask for common area. Space for having lunch. Space for just ordering tea and sitting/taking a break. Make sure it will remain. Make sure it is mentioned in the contract. In one of the spaces we were in, common area suddenly was sold off to a client. Ensure that the common area is spread out. Nice to have – common areas / nooks spread out across the floors. Common area is different from play area. If your team is young and fun, look for TT tables/foosball etc. Again, make sure / ask if it will remain and won’t disappear.
  • HVAC (Air-conditioning) – This can really mess up workspaces and your team. If the floor has central AC, check who has access to the thermostat. Make sure it is handled only by the fac team. Walk around and check if temp is uniform. AC draft balancing is a science. Inspect on two separate days at different times – If it is too cold or too hot on either of the days, something is wrong. And if it is wrong on that day, it will be wrong many days. (Same as washrooms). Non-negotiable. At one time, my guys were wearing hoodies and working.
  • Infra – Check for seepage. AC duct drips. Glass cracks etc. If these exist on both days of your visit, then the team isn’t good enough to maintain the facility. We had buckets under the AC ducts in one of our workplaces.
  • Meeting rooms – Check if there are enough for your team. Check if at least some of them have TVs / whiteboards. Check if the TVs have HDMI/Chromecast. Check how to book meeting rooms. If they say whatsapp or physical book/register, run away.
  • Even if one of the meeting rooms has a sign saying – “Reserved for company Foo” on both days, think twice. Long reservations of meeting rooms for companies does not usually bode well for others.
  • Food – Best case scenario if the Coworking space has a wet kitchen on a terrace of a cafe attached. Food brought in from outside and heated doesn’t usually bode well. Do peek in to the pantry/heating room. Check for hygiene.
  • Pantry – Coffee/water dispenser area – bare minimum. Take a close look at the counter where the coffee machine / tea / sugar is kept. How clean is it? Can give you an approx idea as to how effective housekeeping is. Look at the sink. Loaded? Clean?
  • Internet – Look for the wifi routers. Ask about how one signs in. The best guys have location based auto sign-ins. Sub-optimal ones have a user-name/password to sign in. Check the speed. Ask the community manager to show fast.com results on their mobile. Check if they have back-up internet providers, if one provider conks off. Ask about any specific requirements like – we needed port forwarding and a static IP for our biometric machine.
  • Housekeeping staff – In both of your visits, look out for house keeping staff. Are they on the move. Are they even there? Ask for the cleaning schedule. Do they deep-clean on weekends? How many staff they have? And who supervises them? How does one request help from them?
  • Parking facilities – a lot of the co-working spaces do not have enough car parking spaces. Two wheeler spaces are available though, but they are paid for. Check the process for that.
  • Entry / exit formalities – Ask explicitly about security deposit, what it covers. If you are customizing stuff, explicitly check if there are any re-fitting charges. We removed a glass partition and were shocked to hear about a refitting charge !!

Over-all, basically, if you are working out of a co-working space, there are always trade-offs / sub-optimalities. These are proportional to the per-seat rent in most places. The higher you go, the better it is. There might be exceptions of course.

It is up to you to figure out, at which point your company is, how much you can pay, and which of these trade-offs you can live with. Happy co-working folks !!

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.

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.

 

Informational Call for Potential Leadership Hiring

(img src: pixabay)

After a recent (particularly depressing) informational call for a Leadership position, I thought, I would pen down my thoughts on how an ‘optimal’ first conversation should be.

Some disclaimers: They are in no particular order of importance. These are my opinions. Your mileage may vary – but I would love to hear them, if you have one.

  1. If you are the Head HR and if you are going to get one of your junior HR folk to call/schedule/email details, please have a template or review the language. Firstly, don’t call it a HR interview (*gasp* and please don’t let the subject line be “Call Letter for HR Interview”). Secondly, it is not an ‘explanatory’ round. It is ‘exploratory’. I am not blaming the poor junior kid. It is up to leadership to ensure the right template is available.
  2. If this is an informational, please go first and talk about yourself and your company first. Informational does not mean, me going over my bio (while I really don’t have anything against that). I would rather go over some pertinent points if you have any questions (such as – why I left a certain company, or how was the difference in working between company foo1 to foo2 etc).
  3. Please do not ask me, why I am so pumped up and want to work with your company. For starters, I am not, and hence my request for an informational. Truth be told, an acquaintance of mine thought I might fit your requirements and had forwarded my CV to your CEO. So I think, it is more on you to sell your role to me.
  4. Immediately after I have told you how much I made in my previous stint, please do not say – “Oh. We do not believe in paying too much upfront. You have to come in and prove yourself and then we will see.” * Ouch *. Really? For starters, this conversation should ideally be the last thing that I should be speaking. Not in the informational.
  5. If you are evaluation process is — “First we will give you a case study round. If you pass that, then we will get you to speak to our leaders” — sorry, you have already lost me. You do not hire leaders this way. I am all for a case study round. But that is much later (imho).
  6. Make me feel good. Make me want to learn more about the company. How did the founders start this up? Ask me if I know about all this. Share interesting anecdotes. Give me data about how you are doing. About the diversity of people in the company. And the energy. And I can go on.
  7. Tell me about the team. Tell me why you joined the team. How much you enjoy working with this team. (And no, please do not use yourself as an example of how you joined without much of a pay hike, and you had to work hard to prove yourself, and then got really good rewards).
  8. Please be exactly on time. 3-4 minutes late, to me, is not Ok.
  9. If this is a video Skype call, please do not walk around your home/office/home-office. Yes, your wifi will break. Skype will freeze. And no, I do not want to see your home/offi….
  10. Lastly, at least, ask me if I have any questions. I sure did have quite a few. But they remain unanswered, and I probably do not want them answered at this point in time.

Find below a template that I put together, that can be used by HR/Leaders to have a first round informational for a prospective leadership hire.

  1. Say hi, hello. Get to know how the candidate would like to be called. Enquire stability of the internet/phone connection.
  2. Set the agenda.
  3. Talk about the company first. History. Team. Anecdotes. People. Funding.
  4. Talk about the role. Talk about what exists. What you are looking for?
  5. Ask the candidate for what I have enjoyed in my career journey so far, and what excites the candidate. Ask if there is anything special that stands out in the candidates CV.
  6. If the candidate already knows about the role — ask how she thinks she fits in for the role. Else, poise a question to ponder over – to get the candidate to think if she might fit the bill.
  7. Brief the candidate about the interview process and who are the people whom the candidate might be meeting with. Maybe even a bit about the role/position that each of them play.
  8. Give time for asking questions about the company/about the role.
  9. Give an opportunity to the candidate to think about this, and ask if the candidate might want to think about all this/digest and then come back – if she wants one more informational round – perhaps with a senior leader, maybe.
  10. Clearly sign off with a good note. Express that you are looking forward to these series of conversations.

 

I offer coaching/training on Leadership hiring for Senior leaders and HR. If interested, please ping me on gcmouli at gmail.

Chief Customer Experience Officer

img src: seriousstartups.com

Follow-up to a mini post on a very pleasant customer experience with Bigbasket. I strongly feel that, any company which is interacting with customers on a regular basis, should have a Chief Customer Experience Officer.

Penning down some thoughts on the same below.

  • I did think for a little while, that this should be a major responsibility of the product leader, but on hind-sight, I do not think so. It is a large responsibility on the product leader to think about the customer and evolve the products/services of the company towards that, but there is much more that the product leader does.
  • I strongly believe that, a role focussed solely on the customer is much more beneficial than, it being part of the role, of another executive. It demands and deserves a separate role.
  • The CCXO (sure, it is a four letter acronym, and overlaps the generic CXO, but this is purely hypothetical) should have far ranging powers that span cross-functional domains.
  • The CCXO should be comfortable with tech, marketing, business, field, operations, and most importantly with the consumer landscape.
  • The CCXO should be the person who knows the most about consumer environment, pain points, and behavior.
  • The out reach of the CCXO evolves over time, because the environment, pain points, and behavior evolve over time.
  • The CCXO should have be the voice of the customer and be emboldened enough to argue against any/every other function in the company and fight for them.
  • The CCXO and Product Head should work very closely in planning out current features and future roadmap.
  • CCXO should have his/her own data sets and inferring mechanisms to make sense of the customer base, and impacts being made.
  • CCXO should also work closely with customer support and ensure delight and redressal happens without fuss. Processes and exception mechanisms, and empowerment of the team are important here.
  • End of the day, the CCXO is charged with creating beautiful customer experiences that are worth remembering.

Idea meritocracy

Was listening to this awesome podcast from the Knowledge Project (of Farnam Street fame) with Ray Dalio, where he talks about idea meritocracy. Found it fascinating. Such clarity in thought.

“There are two things that one needs to do to be successful in anything. 1) Take the right decisions, and 2) Have the courage to execute on these decisions.”

Ray, then talks about how he makes decision. Over the years (he has been running Bridgewater Associates, one of the largest hedge funds in the US), he has developed an algorithm on how he makes decisions. He also writes in what he calls a decision journal, where he documents the criteria for making the decision, information that he takes, and his process to take the decision.

One of the things that he talks about is idea meritocracy. Some of the key points that I understood were –

  • All ideas should be treated clearly and put on the table.
  • Each idea should be considered without a bias.
  • He talks about thoughtful disagreement ~ where one needs to agree/disagree and dissect the idea with an objective view.
  • Two kinds of decision makers – autocratic and democratic. Neither work.
    • Autocratic – the bossy types – who eventually make the decision, based on their own thoughts/opinions.
    • Democratic – who always lean towards public opinion and consensus.
  • He believes in making a decision based on discussion (and hence thoughtful disagreement) with people with high believability scores. Believability is based on competency and experience.
    • Example that he gives – I need a medical opinion. My believability score is pretty low. Doctors who specialise in this field have much higher believability scores. Get at least three of them to discuss ~ preferably even disagree and debate between themselves.

I think, I will definitely read his book – where he outlines a lot more. And will update here then.

Communication of bad news

img src: https://commons.wikimedia.org/

I just read T.N.Hari’s excellent write up on “Firing someone you deeply admire.” Brought back a lot of memories of the last few days of Stayzilla. There were anxious moments, and then resignation to what had to happen, and the morbid planning sessions. Morbid because, they are just emotionally taxing, but it has got to be done. What has to be done, has to be done. And in the most humane way and with utmost empathy. A lot of thoughts flew through my mind, as I recollected those days, and I thought I should jot them down here.

  • Proper crafting of communication is super super important. And I feel I am still understating it. The message, the timing, the tone … all of it should be crafted very carefully. These messages touch raw nerves.
  • Communication should be consistent across the organization. What the sales leader communicates to his team should be exactly what the Engineering leader does, and what the Product leader does, and of course, exactly similar to what the CEO says, in the last townhall.
  • In the event, the above cannot be done – sometimes it happens that some functions need to be given a different message – all leaders need to know what the different messages are, and why they were different. Because, there will be questions, and you should answer them.
  • Timeline of events on the D-Day is very critical. There should be absolutely no ambiguity. For instance, in the first instance of letting go, at Stayzilla, in the town-hall, it was announced that, some of the folks are going to be let go, and their managers would let them know. We timed it in such a way, that we had the emails ready to be sent, and were fired off the minute the town-hall ended. Folks should not have to wait and second-guess stuff like this.
  • Empathy is the single most important thing during these times. And by that, I mean genuine empathy. It is extremely difficult when the decision goes against folks whom you know well, and especially hard, when you know it is not fair on that individual (decision was not made based on performance).
  • Organizations tend to be uneven and imbalanced sometimes. It is important to share the load of communicating bad news and lending emotional support, between leaders. For example, the dev team was much larger than the product and design teams put together. Hence, the product leaders took on some of the engineering conversations too.
  • Of course, care has to be taken, that the leader communicating the news has to have had some professional relationship with the person on the other side. Else it is just apathy.
  • I had superb leaders from whom I learnt from, during this very difficult time. One must dispose of one’s ego, and be open to learning and sharing, during these hard times.
  • I wish, this is one thing that founders, and other leaders, get coached on. I have seen and interacted with several people who fail miserably in these soft people aspects. And I think it is incredibly important. God forbid, such an eventuality should never occur in your org, but one must be prepared.

The above points are in no particular order. I just did a tweet-storm on it, and subsequently expanded them into this post. Would love to hear your thoughts/experiences on this.

If you (or someone in your org) need coaching in this area, please ping me at gcmouli at gmail. 

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)