Inspire, empower, listen & appreciate. Practicing any one of these can improve employee engagement; mastering all four can change the game.
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)
A hiring decision should never be a democratic decision.
The interview panel gives its recommendations -> and then the hiring manager gives his observations. It is the hiring manager’s single call – with the recommendations factored in.
Some mechanics and rules (such as categorization between hire/no-hire/weak-hire etc) can be brought in to break ties and help the hiring manager strengthen his view point, but it should be just that.
The hiring manager should have his veto call over the others. The accountability rests on him to hire whom he thinks is the best hire. The buck ends with him. The minute it becomes democratic, the buck starts circling. The accountability dilutes and spreads out. There is no skin in the game. Too safe. No risks. This can never end well.
Portfolios: HR sourced UI/UX candidates for me. We took on only resumes which had pointers to their portfolio (in Behance or elsewhere). If they did not have a portfolio, I did not consider them serious enough to be applying to us.
UI/UX designers vs Creative Designers: There is a fair amount of ambiguity that candidates typically play on, between UI/UX and creative designers.
My definition of a UI/UX designer is a combination of visual design and interaction design. In other words, the candidate should have designed web or app flows (or atleast part of them). These guys have the knack of leading a user through a flow. They know the importance of consistency, primary colors, templates etc.
Creative designers (per my definition) are those who focus exclusively on visual design. These are folks who are exceptional at creating marketing collateral content (such as ads, brochures, posters etc). These are guys who are awesome at designing stuff that will catch your attention. They know the contours and contrasts that will stand out. They know the colour palettes that will work better on banner ads vs print vs mobile.
While hiring for your designers, you should be able to distinguish (to a large extent) at the very beginning what kind of work that they have done, and what their strengths are. Most folks tend to sell to you that, they can do both. I am not a full believer in that yet.
Talk to the candidates: My lead designer and I used to have an intro call with every one of these candidates. You can figure out the ambiguity that I talk about (above) very easily in this call. Talk to them to get a feeling of whether they would fit in, into the culture. See if they can express themselves to you. They need not be eloquent (most aren’t) but they need to get their point across.
Sample project: Those, who pass the phone call, I had our lead designer send out a sample project to them. Depending on your timeline to hire, this can be as small as redesigning/reimagining a page on an existing app/website; to as big as redesigning a process (the payment flow for instance). We used to give adequate times for these. The smaller projects are 1-2 days, and the larger ones 3-4 days. There is a reason for this. Designers typically take time. One cannot push designers hard, like you can do to engineers. More number of hours does not equals more work, in the case of designers.
We also took a look at how these sample projects were submitted. It shows the seriousness of the candidate. There will be candidates who will submit PDFs. They will be some who will submit sketch files. And there will be some really good ones, who will give you an invision file, with sample click behavior and everything.
In-house interview: For the in-house interview, the candidate should talk to one Product Manager (PM), one front end engineer, lead designer, and the hiring manager. If all goes well, one round with the HR.
You probably guessed why the above people were chosen to interact with the candidate. Yes. These are the guys who will be working with the designer. They are the stake holders. You need to know how the designer interacts with a PM and a front end developer. These are one of the touchiest relationships.
The PM dreams of impossible stuff to design, and the front-end engineer would refuse to code it up. And the designer is stuck in the middle, typically. How assertive is the designer? How much data is being requested from the PM? Is the designer trying to understand why the front end engineer is saying, something is not possible?
The interview with the designer is typically to touch upon the technicalities. What are the tools he is familiar with? Is he an expert user? Or very novice. How well does he know his interaction design? A lot of this would have come through the sample project. Typically the lead designer (or me) would probe as to why the designer designed the sample project in a certain way. If there is any plagiarism or this was a fluke, this will come out now.
History and lessons learnt: Contrary to what everyone thinks, the designers job is a very hard one – playing to the tunes of multiple people and scenarios. They have to walk a very thin line between being creative, and delivering within time pressures ; between making a noticeable change, and preserving your style guide ; between taking up a largish revamp of a page, and making a dozen tweaks for the short term ; taking a call between what the PM thinks, the designer thinks, and the customer perceives. I typically ask the designer, what are the lessons he has learnt on the job, while being a designer, and listen. I would expect some of these above thoughts to come out. If they did not, he has been too passive a member, and has not contributed enough. I probe into some of these thoughts, and see what are the learnings that the designer has been exposed to.
Endnote: I had hired a lot of engineers in my career, but hiring designers is a totally different ball game. It is not a 0-1 decision problem. You cannot hire a designer because he knows his tools really well. Designers are creative types, and for a large fraction of them, it is hard to gauge attitude and personality. It needs time and effort to hire the best designers. But once you get them, you are set.
Disclaimers: We were a product based company. I was hiring UI/UX designers.
Fantastic interview with Richard Branson at TED – Monterey. The humility of the man blows me away.
My biggest takeaway quote from this:
Genuinely, if I bought something or had a particularly bad service in something that I did, I would go and do something myself to fix the problem. Like the time, I flew an airline, and I got really bad customer service, and Virgin Atlantic was born.
I have always been a great fan of Seth Godin. Awesome ideas. Straight forward. Talks from the gut. Passionate.In this short pitch, he talks about how different management and leadership is.
Watch the video by clicking on the below link. (Embed permissions are restricted by the owners).
(image courtesy: screen grab from above interview)
I was reading this great article from an ex-Flickr employee on how Tumblr (and its employees) should ride the acquisition wave. In specific, I think some of these points are awesome, immaterial of the current scenario (Tumblr + Y!). These are applicable in almost all big company buys smaller company scenarios. I am reproducing the four points below with some of my observations that I went through during the one acquisition I went through and a few which I have closely seen happen.
Don’t pretend it’s not happening or that it doesn’t matter.
Totally nailed it. It matters. You need to soak it in. You need to absorb in some of the acquiring company’s culture. Make new friends. Get some folks with whom you can gut-check processes. Most importantly, make friends with the non-tech crowd at the bigger company – HR, Finance, Facilities. You will soon realize you would need their help. And help is so much easier to get if you are on their side.
Don’t forget you’re awesome.
You got acquired because the parent company felt that either your technology is awesome, or your talent is awesome. Either ways, you are important to them. Acknowledge that. Dont succumb to giving up everything. A good merger/acquisition is a layer-by-layer mixing of what is best for the joined entity. Do not give up silly little traditions when you were smaller. At the same time, embrace larger cultural practices from the bigger company.
Plan for the Bear Hug.
I think the original article nails this one beautifully. In the initial stages, everyone will jump in and give you ideas. Embrace this togetherness, but have a point-contact for traiging these requests. Else you will get in to a rat hole.
Now you can. You can think beyond the local market. You can think beyond the handful of customers you have now. You can think beyond restraining marketing budgets. You can ask for help in designing UI. You can ask for data. You can do so much more if you start thinking bigger.
Know how deep the rabbit hole goes.
Now this is one thing, that I have seen happening right in front. After the acquisition happens, there are a certain set of things that happen either due to standardization (example in the article is moving to a common data center, which happens everywhere now), or something that resulted from you thinking bigger. Some things might seem easier when doing it on a larger scale, but along with, comes a ton of headache. Localization, internationalization, local laws, patent disclosures. And I fully agree with the advise in the article about – “Dont be afraid to get a gut-check from someone in the parent company.” These headaches have a thing for magically appearing only mid way through the project.
Read the original article here.
- If you are not moving forward, you are moving backward.
- If you are not growing, you are actually contracting.
- in the world of work, every day is exam day.
- Congratulations on all the great work, that you’ve put into your education so far, but your learning has just begun.
- Ironically, in a changing world, playing safe is one of the riskiest thing to do.
I don’t remember which stage it was. It was just after Marissa Mayer took over the helm of Yahoo. She was being asked – “What is Yahoo!”. It was true. Yahoo was going through a bad identity crisis. Yahoo was tottering aimlessly. It was the poster brand. And now, no one knew what it was doing.
It took a while, but I think Marissa has a repeatable answer to that question. There are two messages that are coming out.
Identify daily habits of Y! users and take them Mobile
Make the daily habits so damn good, that users would love it and be delighted.
I think this is a great mission. Mobile is so ubiquitous now. So much so that, there are people who are forming habits using mobiles. Alarm clocks. Foursquare check-ins. Twitter. Figuring out where to go for lunch. Checking their calendar. Folks cannot do without their mobile for some of these tasks, or should I say habits. If you are able to focus on a handful of Y! apps which have become habits, and make the experience fantastic. That makes a lot of sense.
There is some criticism that, she sounds like a broken record, but I disagree with that completely. If she was not doing that, then the press would be saying that she does not have a cohesive strategy. At the point in time, where Yahoo! is, I think what they need is a well defined cohesive mission. And repeating it a 100,000 times is not a bad thing at all.
Way to go Yahoo!. I have always been a Y! fan. Would hate to see it going down.