What to do during 4 years of engineering?

Quite a few nephews (cousin's kids) are getting into college this year and I've been repeatedly asked suggestions about what college, what branch etc. would be better. My simple reply to most of them is "It Doesn't Matter, they won't get a Job". Decide the college and the branch with this thought in mind and you will decide better. What will matter at the end of these 4 years is how much they can learn about surviving in this wild world. 

I've been thinking about doing this post for long but then, finally, I put down my thoughts today. What triggered this is that a stranger read some of my answers on Quora and reached out asking similar questions. Thanks. I hope this helps you too. 

It's great that you are thinking about making the best of these 4 years already. I wish you the best. 

As of now don't worry about a job/startup. Just try to do more of what you love to do. If you think you would like to do something, go ahead and try it out. Create opportunities for yourself, don't wait for them to appear. Only by trying multiple times will you learn if you like to do something or not. I have tried my hands at 70+ things (yes, I maintain a list) to learn which of the things I love doing versus which I do not enjoy as much.

But, money is important. The earlier you learn about it, the better it is. Let me give you some fundamentals of money making with some over-simplified examples. 

There are only two skills required to become wealthy - 

1. Creating something, 

2. Selling something. 

Everything else is labor. 

Anything that gives you money in exchange for your time is "labor". E.g. a Doctor can only earn for as many hours as she can spend. If she earns 1000 per hour, She can only earn 24000 per day (which is not even practically possible). But, if you have created something that can be copied and sold - you have a product that can earn a disproportionate amount of money even when you are not working on it. E.g. You build an App that users buy, you create just once but people will keep buying it even when you are sleeping. There is no real limit to how much you can earn because it's not dependent on time. 

So always try to learn these two critical skills of creation and selling. Creation is not only about software or hardware, it can be concepts, art as well. Selling - in itself is a complex thing. You need to learn management, communication, positioning, psychology, negotiation, statistics and quite a few other things. It can look overwhelming, but you have a lot of time. 

How you learn Selling, is by learning about people. How you learn about people is by:

1. Reading - Read a lot. Read anything, everything that you find interesting - fiction, non-fiction, history, news, business. Over a period of time, interests will keep changing and you'd learn a lot about different things. Reading books is one thing and reading situations is another. Ideally, Travel helps you learn the most about people, and books are a good hack since you may not be able to travel as much. 

2. Applying - Don't miss a chance to sell. Sell your ideas. Sell what you have created. Sell your services. Organising clubs and events at college can be a great learning experience for all this. Make friends with a lot of people. Do public speaking, volunteer, do social work, play sports.   

Since you are going to be into engineering and you like programming, you'd definitely acquire the power of "Creating" something.

Learn any technology deeply. Try to use it for the simplest of things you want to do. Learning even the oldest - C/Java language can be very helpful. All technologies are similar, just that the syntax used is a bit different. In fact, you may not try to learn the latest and most trending thing. Because trends phase out fast. The basics last forever. However, it would help to learn machine learning since the world is getting data rich very fast and they need more data engineers than ever before.
  

Certifications

I don't believe in certifications. It's just a standard external validation that you have learned something. Doesn't tell much about your abilities. Do it if you like it. Its value is always doubtful. However, learning is always important. Self-learning is the best bet. One awesome way to learn is by creating stuff and learning all that is needed to do that, another one is to help others in learning something. Udemy/Coursera have opened up so many opportunities to learn online from the best teachers in the world (sometimes for free or at very low prices). Take those free courses sincerely. I have moved from tech to business and moved up the ranks without any business degree. I've just leveraged a lot of these free courses, slideshare, and ebooks. Being sincere is more important than being serious. 

Learn about open source see how much software people all over the world have written and shared extensively for free. Fork repositories on Github, share all your ideas and creations freely and extensively. Connect with people who you can't reach out to, on Twitter and Linkedin. See how you can help them. The Internet is your friend, always feel free to ask questions and give answers. Ecosystem works that way - if you can give, you can take. 

Don't forget the FUN part. 

The reason I keep repeating Do What You Love - is because that's where the fun is. We are always bound by things that we are obligated to do, so doing something just because you love doing it is extremely important. I'd just want to add that sometimes it is ok to not do anything, idle around, gossip with friends and watch TV. Have fun while you are learning, and learn while you are having fun.  

Cheers, feel free to reach out to me if you have any specific questions or if you feel you are stuck. All the best. Here's something that you'd find helpful as well.



If you have reached this far you should totally leave a comment about how you liked it and share this post with others.   

Evolving A Sprint Process That Everyone Loves

What is fun for a team of 10, quickly turns in to a nightmare for a team of 25, and a disaster for a team of 50.

Every time I see a startup scale up, I find them running in to and complaining about quality issues, communication break-down, stressful work environment, demotivated teams, and chaos. Typically, all the roles that CEO/Founders were doubling up as (Product/Tech/Sales) pretty much need to be handed off. And that demands a quick influx of team members who can take up these responsibilities. And it also makes people adopt standard processes that seem to have worked for others. That, unfortunately, creates even more stress.

When new people join, they bring in new knowledge and experience, and also a baggage of cultural orientation. And they are expected to hit the deck running. So, without being immersed in org culture, they have to take up critical communication and leadership roles. What you end up doing as a founder is distancing yourself from the core team you once managed directly. Even if you are pro flat hierarchy, what you are creating is still a hierarchy. And when done all of a sudden, it creates subtle panic and chaos. While startup life is all about chaos, ability to organize and structure this chaos is what separates winners from losers.

The success of a product is undeniably a function of its quality. And software product quality, in turn, is a function of its development process. You don't realize it initially because passion trumps over the silly hacks, issues, rework. But as you start hiring beyond your core team, you'd have people in the org with whom you communicate via other people. Unorganised/Assumed/Naturally-formed structures often create hurdle in the flow of information.

Even a flat hierarchy is a hierarchy. 

The more distance you have from the last node of communication the more important it is to think about setting up a process and create a communication map for the organization. It is critical since the success of your product is directly affected by what processes are you following to build it. In next part of the post, I'd discuss some abstracts from a real situation I was tasked to change and how we, as a team, were able to evolve a process that everyone loved following.

Software development process 

Let me try to describe at the high level, the situation we were in. We were split across different locations with both the product, the design and the tech teams spread evenly across the two locations. Teams at both locations were used to following their own half-baked development processes and tools and even the culture of interaction and cross-team communication were different. Add to that, multiple products with a common set of features, different technologies, platforms and different leads.

The general expectation was as follows:
 - everyone is occupied enough,
 - everyone knows what they are supposed to be working on and why,
 - are enjoying their work,
 - are working efficiently and
 - at any point in time, it is easy to determine if we are making good progress

Nothing exceptional about the expectations. Pretty basic, right?

None of them were being fulfilled actually.
 - people would generally complain they're either too free or too stressed
 - forget the why part, they were frequently breaking each other's code and spending a lot of time in rework
 - motivation? this wasn't really pushed as much by the management. It was more of a personal agenda as I was interested in making sure everyone is happy and content with what they are working on.
 - we had no way to tell if everyone was working at their optimum efficiency
 - every time we needed to determine status, a guy had to go around in the office and gather status

Most org related issues are non-unique. If you can relate to the situation described above, at the high level, feel free to add the people issues, ego-clashes, old versus new, the quick hackers versus the quality conscious, messy details, the nuances, the little friction points, and other problems you've experienced or can imagine. We've probably had most of those as well, in different quantity and flavor.

So now that we have a real flavor of the situation I'd take you through the journey of how we dealt with it all at once, but slowly.

Now, when I look back it seems easy. But, when you're in thick of things it can be really overwhelming. Because, I didn't know the entire problem, and there is no standard way to solve these that I was aware of. Plus, since it was assigned to me, everyone expected me to give them a fix. Like right in the first meeting, the question was what process should we be following from now on?

Answer - I don't know. But, I guess I can never give you a process. We can try a few things and evolve something that works for all of us.

I could feel the disappointment. People weren't convinced. Decentralization can be painful. (Do you hear it, crypto-fans?) However, stubbornness is a virtue sometimes. A weak argument said with conviction lands better than a strong one said without it.

Here's how we were able to evolve a process:

1. Started with a simple Team occupancy chart and allowed developers to share how occupied they are during the next sprint. Let people know you trust their word. They could simply fill it with any number they deemed fit. Usually, we used to get values like 25%, 50%, 80%, and 100%. That was a good reflection of where we stood, and what we need to make all values 90-100%.

2. Created a Sprint calendar. We decided on 2+ Week Sprints (meaning it should have 2 weeks of development ). It started with a Backlog refinement meeting where we made sure we had enough time for developers to do estimations, development and enough time for the QA to test and release. So technically, it was 3 weeks between the start of the sprint to production release, but in-effect we had releases every two weeks. Religiously did Retrospective meetings to understand the problems and solve them one by one. Made sure it is followed. Trust is important.

3. We identified 3 KPIs that we needed to improve. There were more KPIs on and off, but these stayed throughout. This was the crux of setting up the new process.

•  Minimize creep: the tasks being added in the middle of the sprint.
•  Minimize rework: (reopened tickets) for developers and testers.
•  Minimise residue: tasks left over at the end of the sprint.

The first sprint meeting was not really about introducing any process, but just making everyone cognizant about the KPIs. When we did the first retrospective, people were listening more seriously and suggesting how we could improve stuff. And from the second retrospective onwards we started seeing some improvement.

4. Improve communication, encourage everyone to speak out openly. Not everyone knows how to articulate their issues well so bear with people getting worked up. Accept mistakes. Don't point other's mistakes, allow them to accept it. Don't allow others to point a finger at anyone, let people get comfortable to own up. Give people enough time, keep asking "what else". Once we knew the KPIs, everyone had really nice suggestions to improve them and we just accepted and experimented with most of them.

5. Note down action items. Assign it to people and Convey it to them clearly. Follow up.

6. People felt empowered and started looking forward to this meeting. We started with checking progress on the KPIs, and then the retrospective basics - what went well, what didn't go too well, what needs to change. What initially took 90 minutes started reducing down to less than 60 mins of meeting.

Impact

It took about 4 sprints to have a process that everyone was happily following. Here's a quote from one of the emails I wrote when I introduced the process - "The idea is not to have process overheads but be little more disciplined and organized in our work so that we can get stuff done with less stress." 

The process wasn't created, it was evolved. It was a loosely defined process that evolved over a period of time and everyone contributed to it. It wasn't set in stone but everyone knew how to go about doing their stuff. Most of the decision making was still left to people's judgment. Some of them needed a little handholding here and there, but most of it was smooth.

• Everyone was occupied enough and we knew who's free when. 
• Overall there was a sense of belongingness, content
• Work was more evenly distributed and everyone knew what they are doing through the week (and weekend ;-))
• Every day we had a clue about where we stand and how things are progressing

Achievement (1500% improvement)

The entire exercise did not dramatically improve our efficiency. But, we exactly knew what's feasible to deliver in what time without stressing everyone. The high point came in when we were able to optimize an annual exercise, that historically needed a stressful fortnight. It was reduced to just one late night effort. 15 days and nights of stress got reduced to just 1 night. A 1500% improvement would sound outlandish, but, numbers are funny.

I hope this gives you some clues about how you can improve the development process in your organization. I am happy to take up any questions you might have.

Liked it? Have questions? Write it out.



If you have reached this far you should totally leave a comment about how you liked it and share this post with others.  

Building the Product Roadmap

I recently talked about creating an effective product roadmap in this Antwak series. 

In one of the earlier posts, I talked about how to make a data-driven product roadmap. Deriving your goals in themes like Acquisition, Conversion, Money/Revenue, Engagement makes things a lot easy for keeping the roadmap data driven. Also, in the previous post, I talked about various brackets in which the features of a software product can be categorized. 

I felt the list of brackets can also help in getting ideas for a comprehensive list of tasks for the roadmap. 

Here's the list of those brackets again with some more details and examples. I'd soon add a link to the template for a product roadmap. (The list is not in any particular order.)

Feature Brackets for a Product Roadmap 

1. Parity Feature

A feature that the competition (if any) already has. The kind of features that you need, to be 'at Par' with them. The kind of features that your prospects will compare and ask questions about when you try to close the sale, especially for SaaS products. In case of consumer products, you wouldn't have loyal users mostly. You can be in good books of consumers as long as you keep providing at least what your competition is providing.  
E.g. Integration with Slack (for a Reporting Software), Price comparison (for e-commerce), Video call (for chatting app), Panic button (in a ride-hailing app) etc.  

2. Expected feature 

A feature that's naturally expected from your product. It's generally the USP, but also, includes conversion and revenue related features. In 2012, importing contact book was a disruptive feature by WhatsApp, as of 2017 importing the contact book is an expected feature for a chat application. 
E.g. Signup/Login, Home Page, Subscribe (for content-based product), Purchase module (for SaaS/E-Commerce)

3. Advanced feature 

A feature that only a power user would love. Usually, a first time user may not get it, or care about it. For someone new to youtube, it doesn't hurt that you can't filter a certain type of videos. But, as a parent and longtime consumer of Kid Video, I strongly feel the need for it. Youtube hasn't heard me yet. [Update: Youtube does have a Youtube kids app, however, a filter would really help so much more]
E.g. Customisation options like Themes, Font Settings, Filters 

4. By-products 

What perhaps 3rd parties are providing on top of your solution. It may also be an unexpected use of your product. Check my last post for more details. 
E.g. Facebook for Business, Google Tez, Youtube-kids (special app for kids) 

5. Unexpected feature 

Unsolicited, clever add-on features that can delight users in certain situations. 
E.g. Panic button in Ola (a cab hailing app), Forgot attachment notification on Gmail. 

6. Repayment feature 

Most of the time you are hacking stuff to get it out of the door. You should plan it such, that all the stuff that you kept for "later", don't get too late. Reducing technical debt, legal debt, doing compliance related stuff. 
E.g. Technical Architecture, Optimising performance, Documentation, creating really useful terms and conditions, Disclaimers, EULA, Security certifications, Government licenses and approvals etc. 

7. Engagement feature 

A cab-hailing app also allows you to store frequently visited places as favorites. An e-commerce website also allows creating a wishlist. These are not the primary use case, nor do they awe the users. They just give a sense of completeness to the product. Engagement is about providing a complete ecosystem for the user to feel connected with the product. Obviously, these features have the potential to hold the users longer, bring them back often. 
E.g. "You may also like", Favorites, Cashback, Leaderboards, Newsletter Subscription 

8. Viral feature 

Will get you more users. More often they are targeted for providing exceptional growth for a limited time. 
E.g. Referral Schemes, Incentive to Add your contact Book etc.   

9. Security feature 

Keeps your product, your users and/or your data safe. Some basic security is always appreciated by the users. Nothing is hack proof but you can ensure that it's not easy for a school kid to put you to shame - at least in the early days.  
E.g. OTP verification, Https, Pattern lock on your phone, Captcha, Re-Login 

10. Instrumentation feature 

Features that help you measure and monitor the growth/health of the product. If you are not measuring you are not improving. 
E.g. Integration with basic Analytics, integration with advanced analytics, integration with   

To understand which feature bucket is more important at which stage (early, growth, maturity etc.) of your product you can have a look at this previous post. This should provide a good reference to make sure your feature list and roadmap is both comprehensive and stresses on the right areas at the right time. 

Thoughts? I'd love to know your thoughts and comments. Please take a moment to write them.  




If you have reached this far you should totally leave a comment about how you liked it and share this post with others.  

Product Prioritisation - More than Impact v/s Effort

I recently had a nice long discussion with a product manager friend working for an e-commerce giant. Among other things we talked about prioritisation and how we do it in our respective organisations. I had some interesting thoughts and I talked to PMs in a dozen startups in India to understand how they are prioritising for their products. I realised that other than the famous impact versus effort analysis, there is an invisible framework we use to determine impact at different stages of product life cycle.

This is how the standard Prioritisation chart looks like:

1. high impact, low effort - slam dunk! obviously, go for low hanging fruits

2. low impact, low effort - I personally love these micro-optimisations. They can quickly add up to become high impact

3. high impact, high effort - the bigger projects. See if you can release them piece meal and turn them into a mix of 1 & 2.

4. low impact, high effort - why would you ever want to do these? Well, sometimes you have spare resources. Also, sometimes these are Parity or Expected features and you need to have them for the sake of completeness.

In my research, though I found more layers of complexity involved in making a decision. Notably, at different stages of product life cycle, the prioritisation is managed very differently. Whatever methods are being followed, almost no one was "consciously" considering the prime responsibility of product management - balancing business, users and tech. It was being done rather instinctively. I also figured that for most products, all their features can be grouped under certain brackets.

I found that if articulated, the framework can act as a very helpful reference while prioritising features for any B2B, or B2C product roadmap or even for doing backlog refinement for sprints. I showed it around and most PMs could relate very well to it.

Here it is. I classified different features into various brackets and I could find 10 of them. I tend to feel this is an exhaustive list of the feature classification, but let me know if you can think of more brackets that can be added. (In no particular order)

1. Parity feature - a feature that the competition (if any) already has 
2. Expected feature - feature that's naturally expected from your product. Also, includes conversion and revenue related features
3. Advanced feature - something only power users would love 
4. By-products - what perhaps 3rd parties are providing on top of your solution. Check my last post for more details.  
5. Unexpected feature- unsolicited, clever add-on that can delight users in certain situations
6. Repayment feature- reducing technical debt, legal debt, compliance related stuff
7. Engagement feature- will hold the users longer, bring them back often
8. Viral feature- will get you more users
9. Security feature- keeps your product/users/data safe 
10. Instrumentation feature - helps you measure and monitor health of product

Eventually, you'd have to put features in the Impact versus Effort chart and assess what to build. Impact estimate should cover who is it going to impact, and how much is it going to impact them. Effort estimates are what the tech team says they are (in person-days or person-months).

Practically, in larger teams with enough resources, the effort estimates are less important. 

Sorry for the digression, i know that's politically incorrect. But, I care less, that's a truth. Effort estimates come in handy only when there are competing features that need to be added and may have similar impact. Also, when resources are low and you have to argue with others and fight for your ideas. It happens mostly in early and growth stage, less frequently in maturity stage.

Now, coming to how at different stages the balancing act assigns different priorities to these feature brackets. Here's how it looks:

Early Stage
(Listed in order of Priority for this stage)

1. Expected feature - This is the core of your solution. You build this first, nothing makes sense until this is ready. 
2. Parity feature - What competition already has. When users come to you, they'd want to compare before they pay. You'd need to tell them you have those features and more.  
3. Viral feature- The referral schemes and social elements and network effects that will push you to growth stage. 
4. Repayment feature- It's important to give it enough weight for a stable, scalable future product
5. Instrumentation feature - This is setting you up for next level. You need to start thinking what you want to measure. What you can measure is what you can improve. 
6. Security feature- A stitch in time saves nine. It makes total sense to keep making security audits. You have less data but this is also the time when those sharp early adopters will try to milk your vulnerabilities the most. Particularly promotions and referral schemes. 
7. Engagement feature - less important at this stage
8. Advanced feature - don't even think about these
9. Unexpected feature- don't even think about these
10. By-products - don't even think about these

Growth Stage
(Listed in order of Priority for this stage)

1. Viral feature- create and fuel your growth engine. (Notice the jump?)
2. Parity feature - This is a necessity at this stage. You can't lose out because of these.  
3. Expected feature - You need to make sure early adopters and the early majority get what they expect, if not more. 
4. Instrumentation feature - the better you measure, the better you grow
5. Repayment feature- don't lose sight of this, it is always important
6. Engagement feature- acquisition may be top priority but if they are not being fed back to the funnel you are losing money. 
7. Security feature- Data is increasing and so is your responsibility
8. Advanced feature - you may start throwing in a feature or two for power users if they are low on effort
9. Unexpected feature- only if they are low on effort
10. By-products - don't even think, unless you see that you need to Pivot. 

Early Maturity Stage
(Listed in order of Priority for this stage)

1. Engagement feature- add more channels for engagement, make users sticky, bring the acquired pool back more often (Notice how this comes from #6 to #1)
2. Viral feature- make sure the incoming stream is steady
3. Unexpected feature- great time to innovate, bring in some fresh thoughts to delight your users
4. Security feature- this is getting critical
5. Repayment feature- stability and scalability are of prime importance
6. Advanced feature - hopefully, now you have more power users to care about
7. Instrumentation feature - measure everything, integrate with third party tools
8. By-products - this goes with better qualitative analysis of your customers and take up side projects for up selling and cross selling to the same consumer base
9. Parity feature - hopefully, you've carved a niche for yourself, but keep an eye on where they are heading
10. Expected feature - hopefully, you've nailed most of it by now so you can stop worrying about it for now

Maturity Stage
(Listed in order of Priority for this stage)

1. Engagement feature- engage more, engage better, time to curb churn 
2. By-products - leverage what you have, before others do
3. Unexpected feature- innovate, disrupt yourself before others do
4. Advanced feature - there may substantial subset of users who care about these
5. Instrumentation feature - the last 4 are only possible when your measurement is intensive and extensive
6. Viral feature- growth is still important
7. Security feature- this is critical. Make sure you have tight security, backups and continuity plans in place
8. Repayment feature- reducing technical debt keeps you stable and scalable
9. Parity feature - you should know your customers better than your competition does, parity is less important than engagement and delight. Never lose your edge
10. Expected feature - revisit your core value proposition, make sure you are honest

Decline Stage
(Listed in order of Priority for this stage)

1. By-products - Your users are moving on, your product should too. See how?
2. Engagement feature- will hold the users longer, milk as much as possible
3. Unexpected feature- unsolicited, clever add-on that can delight users in certain situations
4. Advanced feature - give them what they want 
5. Instrumentation feature - you should have mostly figured this out by now
6. Viral feature- you may try innovating with new channels, geographies, consumer sections if something can bring you back in the stable state. 
7. Security feature - be wary of access permissions, disgruntled employees
8. Repayment feature- make sure technology is not coming in the way
9. Parity feature - not just current competition, check what is disrupting the market
10. Expected feature - revisit your core value proposition

It's fun to see how you can simplify your decision making by articulating things that you instinctively do.

Did you find this useful?

Would love to know your thoughts.
Please comment here or share your ideas with me.
And feel free to share the article if you find it worth.




If you have reached this far you should totally leave a comment about how you liked it and share this post with others.  

Upgrade yourself: Be a By-product manager!

Most PMs I interview for my org, I make it a point to ask them, how do they interact with the customers/end-users. What do they ask in order to assess their own ideas, or identify what user's want. Most of the good ones will answer it around identifying the problem of their users/customers.

Thinking about the problems is VERY important. In fact, it is better than thinking about solutions. But this post is about taking the entire thinking one level up.

What is the by-product of your solution? 

What impact is your solution having on the consumer base. I am sure it is helping them solve a specific problem but what else? Baking soda was originally advertised as a baking agent. Over time, customers started using it as a cleaner and deodorizer. To take another example, Whatsapp was able to help people text, talk, share pics, videos all in one window. But that was the intention. Whatsapp enabled millions of virtual communities to be born and grow. I am part of at least 5 communities related to startups and product management. Maybe I knew just one member of the community who added me and then so on, all communities are buzzing with superlative discussions and everyone is able to help everyone out. LinkedIn as a product is targeting to do such a thing, but it's happening over Whatsapp and Slack, un-intentionally. The best part of whatsapp is its reach. Slack is still limited to Organisation and Tech-savvy folks.

Your product might bring people together, save time, educate them - think what people are able to do with all this extra empowerment (network, time, knowledge etc.).

 - Ecommerce apps like Flipkart let people gift and donate stuff that they were finding hard to buy and ship.

 - IRCTC, Ola, MMT enables me to help my parents, living remotely, have a safe trip whenever they want to. I can mostly track them during their travel.

 - Dunzo is helping you attend the friend's wedding because the parcel will be picked from the station and delivered to destination without your sweat.

 - Bigbasket is saving you the fuel that you would have burnt in finding parking to be able to buy some tomatoes.

Manage the By-products too... 

You can clearly see that some by-products are really strong while some are weak and can be built upon. That's where the By-product manager comes in. You can identify the upshots of your product and build upon them.

1. Identify the upshots(by-products) of your product
• What exactly are users using it for?
• What else are they using it for? Or What is it enabling them to do?
• Other than solving the problem, what are their needs and wants 
• How has it impacted their lives outside of solving their problem. 
2. Explore the new problem scope - new use cases
• Do you see a new feature, product? 
• Is there an opportunity to help them, or take their experience to new level? 
• Is there an opportunity to sell?
3. You may either solve for it, or just leverage it for marketing better

Your product is creating new problems to solve.
New problems are new opportunities. If you are not tapping this, someone else will. And that's why it is extremely important to think outside the current problem scope and think about the upshot for your product.

What's the upshot of your product going to be?  

[Video of my talk at Upstart on this topic] [Slide deck]





If you have reached this far you should totally leave a comment about how you liked it and share this post with others.  

PM Job Seeker's Checklist

I've been helping a lot of techies and accidental PMs to understand the scope of Product Management. So many times that I was able to put most FAQs and basics in this short course. So while this covers the basics, people do come up with more questions on the role, some real challenges they are facing and also about getting the job of a product manager. 

Introduction To Product Management: ChalkStreet

One guy from IIM recently took up a BA role and is now looking to get into PM. But he wasn't getting any calls for job interviews. 

Here's what I suggested. I believe it is also the checklist for anyone looking for product roles:

1. Resume. Not sure if your Resume clearly indicates you are a good fit for the role. Look at the example of another sales guy trying to move to PM role. If you are moving from a non-PM to a PM role, you've to be extra careful that the Resume states clearly you are looking for a PM role, otherwise, the recruiter might just think they've picked an irrelevant resume and trash it. Look for all relevant JDs on Linkedin and tweak your resume to use all the keywords so that it can match those. Mostly the buzzwords are around specifications, PRD, wireframes, metrics, etc. Please make sure you compress your job summary to a 1-page resume. If you have more than 10 years of experience - you can think about a 2 Page as well. Not more than that. 

Before

After

More tips about how to write the BEST resume. 

2. Where can people find you? Better places for a PM role are Linkedin, Hirist, Instahyre, Angellist, Cutshort, and Naukri. Keep all these profiles updated. In fact, if you are applying for consumer profiles also keep Twitter, Facebook and other social profiles active and updated.    

3. Patience: Keep at it. It may take 3 to 6 months if you are doing all the right things, for relevant opportunities to open up. Apply, re-apply with personalized cover letters. Btw, the email that you write is a cover letter, don't write a separate one and attach it with your Resume. That's silly. 

4. Not just what you know, it is also about who do you know. Network! Networking is not just about sending LinkedIn requests. Attend good startup and product related events, join PM communities on FB, Linkedin, Meetup, Whatsapp. Meet people, learn from them, connect at different levels, ask questions, find out what people are looking for. Be active on social media. Engage with relevant folks and comment on their tweets or re-tweet them with your opinions. This will help you understand where you stand and how you can position yourself correctly. Look for ways in which you can help people. That's the best way to network.  

5. Prepare better. The chances you get will be limited, don't mess them up. If you haven't read some of the books like Cracking the PM Interview, Decode to Conquer your preparation may not be complete. At least read one of them. In general, as a PM you should be reading a lot of good books on business, startups, and product design. There are a lot of lists of good books available - here's one of mine. You are expected to know about and have opinions on trending technologies like Blockchain and Machine learning even if it is unrelated. You should also follow some current affairs about your domain. 

I am sure he'd get a job soon. I'd update when he does! :-) 

Update: 23/12/2017 - He is placed at Zynga Bangalore now. 

Update: A More updated deck from a recent workshop I took for Upgrad. In the deck, I talk about how to deal with different types of interview questions and assignments that you get as a part of the interview process.  


If you have reached this far you should totally leave a comment for Ujjwal Trivedi about how you liked it.  

Revisiting the PsychUp Checklist

Based on my previous studies I created this psych up checklist. It is for product managers to be able to quickly evaluate what their products are missing in terms of how well the products appeal to the Right brain of their customers/users. At a recent workshop I took, a lot of participants used it and I was able to find checklist items that people slipped on most frequently.

A lot of it may be due to not being able to understand it or not being able to apply it. I'd work to gather more examples and add more actionable steps so that every one can use it.

However, till that time here's the list of most frequently missed biases, and some of my commentaries.

Salience Bias - If there are multiple things seeking user's attention, the one that is most easy to understand or looks familiar is the one user is going to go for first. Hence, making the most useful feature prominent and most simple to use is very important. Your UI needs to drive the users to do what you *want* them to do.

Stereotype - Making it "look" like a winner. This is very common. Making UI look beautiful is considered one of the last things that people want to do for their products. It's ok. But, if you want to scale and you want users to perceive your product as more valuable, it is important to make it look rich.

Risk Aversion Bias - Making users feel more in control. It's again very important to make your users feel in complete control by talking to their fears and concerns. It's like people want autonomous cars, but I am sure they'd pay extra to buy the one which allows manual driving. Nothing in your product should scare your users, or even make them think or be concerned. Make sure they can reset to default settings easily.

Anchoring - Setting the expectations right. This one is difficult to understand and implement. It does require some diffused thinking and making iterative changes. It is specific to consumption and pricing.

Bandwagon effect - Providing social proof (this was a surprise!). I am surprised that people forget putting testimonials or social proof of who their current users are and what they think. It works like a charm if done correctly. Obviously, you'd have to keep it real and make it look as real as possible and it needs to "connect" with your TG.

Decoy effect - Introducing Decoy pricing plans to make the target plan look more profitable. This one is again a less used magical formula. When you add two price plans, add another no brainer high price low value option comparable to your target plan. When it looks more profitable than something, users end to think it is the most profitable. Higher conversions!

If you have had success stories or trouble using any of these do comment and I'd see how I can help you further. And if you haven't taken the Psych Test yet, now is a good time.




If you have reached this far you should totally leave a comment about how you liked it and share this post with others.