Monday, December 19, 2011
The merger
As I'm planning to revive my blogging habit, I have decided to blog from a single blog address - http://anura.blogspot.com I want to maintain a single identity in the blogging world rather than managing two different blogs for professional and personal reasons. For those who have bookmarked this blog, please update the URL to http://anura.blogspot.com. I plan to retire this blog by end of this month.
Thursday, November 24, 2011
Is hiring the be-all and end-all?
I came across an interesting article a few months back on the difficulties that startups face in hiring good developers. I think "retaining" good developers is also equally important, given the scarcity and attractive offers from large organizations and other startups. I want to address the trivial-but-often-overlooked issues that make a lot of difference in the long run. These issues and suggestions will be applicable to startups with a defined business model and an established core team that is already into execution mode.
The new developer should feel "at-home" right from the first day. HR/Admin in-charge should ensure the IT requirements are addressed before hand so the person has access to his desktop/laptop right from the moment he steps in. A designated space should be made available based on the team members with whom the new hire is supposed to work with. "Sit where there is space" kind of an attitude by the hiring manager could be a turn-off on the very first day.
However busy he might be, the hiring manager should take the time and effort to introduce the new developer to other team members. He should make the new person feel comfortable, appreciate the challenges and learnings of working in a startup and not be intimidated by the work pressures and late working hours required. The manager can also plan for an informal meeting where he takes the new hire out for lunch and explain his role and expected contributions in the next six months.
The developer, having decided to work for a start-up comes in with a lot of expectations on opportunities to grow. A formal training programme should be organized to give an overview of the company’s business model, the current challenges, the organization/team structure and explain where the new hire fits into this whole model. This gives the developer much more understanding of the business and a broader scope where he can apply his skills and explore his potential. Through this training programme, he should get introduced to the technical leads, designers, product managers and project managers who could explain how the development process works in this startup.
Another big turn-off could be blindly handing over the code base and asking the new developer to dig into it to figure out the implementation and fix the existing bugs. A senior technical person should take the effort to explain the architecture of the product and share the thought processes that went behind the design. I'm not suggesting to "spoon-feed" but rather help the new hire to get started in a phased manner that would enable him to understand and appreciate the nitty-gritties of the product/architecture.
The first 90 days period is crucial for both the company and the new hire. If the developer doesn’t get a clear picture on where he fits in and what his responsibilities are within those 90 days, he will lose interest. Either he might drag along with the job for a few more months or start to look out for other opportunities.
The interesting aspect of working for a startup is the dynamic nature of the work, the role and the priorities. There could be new areas of interest which the developer might want to explore and that could also align with the organization's priorities. So it makes sense that the goals assigned to the new hire are established only for a short term and not really span out for the entire year.
I firmly believe that hiring the right set of people and establishing an inspired team can catapult a startup to greater heights. Please comment if there are any other finer points that startups should focus on in terms of post-hiring processes.
The new developer should feel "at-home" right from the first day. HR/Admin in-charge should ensure the IT requirements are addressed before hand so the person has access to his desktop/laptop right from the moment he steps in. A designated space should be made available based on the team members with whom the new hire is supposed to work with. "Sit where there is space" kind of an attitude by the hiring manager could be a turn-off on the very first day.
However busy he might be, the hiring manager should take the time and effort to introduce the new developer to other team members. He should make the new person feel comfortable, appreciate the challenges and learnings of working in a startup and not be intimidated by the work pressures and late working hours required. The manager can also plan for an informal meeting where he takes the new hire out for lunch and explain his role and expected contributions in the next six months.
The developer, having decided to work for a start-up comes in with a lot of expectations on opportunities to grow. A formal training programme should be organized to give an overview of the company’s business model, the current challenges, the organization/team structure and explain where the new hire fits into this whole model. This gives the developer much more understanding of the business and a broader scope where he can apply his skills and explore his potential. Through this training programme, he should get introduced to the technical leads, designers, product managers and project managers who could explain how the development process works in this startup.
Another big turn-off could be blindly handing over the code base and asking the new developer to dig into it to figure out the implementation and fix the existing bugs. A senior technical person should take the effort to explain the architecture of the product and share the thought processes that went behind the design. I'm not suggesting to "spoon-feed" but rather help the new hire to get started in a phased manner that would enable him to understand and appreciate the nitty-gritties of the product/architecture.
The first 90 days period is crucial for both the company and the new hire. If the developer doesn’t get a clear picture on where he fits in and what his responsibilities are within those 90 days, he will lose interest. Either he might drag along with the job for a few more months or start to look out for other opportunities.
The interesting aspect of working for a startup is the dynamic nature of the work, the role and the priorities. There could be new areas of interest which the developer might want to explore and that could also align with the organization's priorities. So it makes sense that the goals assigned to the new hire are established only for a short term and not really span out for the entire year.
I firmly believe that hiring the right set of people and establishing an inspired team can catapult a startup to greater heights. Please comment if there are any other finer points that startups should focus on in terms of post-hiring processes.
Sunday, November 14, 2010
Empathy - who has it?
In the recently concluded Product Manager's Conclave event at IIM, Bangalore, there was a panel discussion on qualities required in a product manager. One specific quality that really made a lot of sense was "Empathy towards customers". However, I'm still not sure how an interviewer gets to validate this quality during an interview for a product management opening.
As a product manager, we interact with customers and try to understand their current problems. If more customers complain of a certain problem, we give a higher priority towards solving it. Nothing new, it's just the basic driver of prioritization. But I believe the quality of empathizing with your customers is not just restricted towards product managers. Everyone in the organization needs to have this quality. I've been reading this book - Linchpin by Seth Godin and he talks about a powerful concept called Emotional Labor. A line that Seth highlights is that "In most jobs that involve a customer, you are getting paid only to do emotional labor". Aren't emotions the key differentiating factor between humans and machines? In an era where every task is getting to a programmable status, emotional quotient (EQ) can become the sole savior, in my opinion.
Talking about empathy and how every individual is expected to have this quality to make a difference to a customer, a product manager can take the lead in enabling other team members embrace this quality. A few ideas which you can explore:
When you communicate the product requirements to the design and development teams, ensure you first talk about the customer pain points and how their current alternatives are creating problems leading to certain negative outcomes - manual effort, loss of time, dependency on other third parties etc.
The same also needs to be communicated to the QA teams as well. Going over the requirements and possible test scenarios come in later. For every product requirement, provide a clear background on why it is important for the customer.
It would also be better if you can take along a developer or a designer during your customer visits. They get to experience a slice of the customer's problems in person which would help a great deal in designing the right solution.
If you have other ideas related to this topic, please comment.
As a product manager, we interact with customers and try to understand their current problems. If more customers complain of a certain problem, we give a higher priority towards solving it. Nothing new, it's just the basic driver of prioritization. But I believe the quality of empathizing with your customers is not just restricted towards product managers. Everyone in the organization needs to have this quality. I've been reading this book - Linchpin by Seth Godin and he talks about a powerful concept called Emotional Labor. A line that Seth highlights is that "In most jobs that involve a customer, you are getting paid only to do emotional labor". Aren't emotions the key differentiating factor between humans and machines? In an era where every task is getting to a programmable status, emotional quotient (EQ) can become the sole savior, in my opinion.
Talking about empathy and how every individual is expected to have this quality to make a difference to a customer, a product manager can take the lead in enabling other team members embrace this quality. A few ideas which you can explore:
When you communicate the product requirements to the design and development teams, ensure you first talk about the customer pain points and how their current alternatives are creating problems leading to certain negative outcomes - manual effort, loss of time, dependency on other third parties etc.
The same also needs to be communicated to the QA teams as well. Going over the requirements and possible test scenarios come in later. For every product requirement, provide a clear background on why it is important for the customer.
It would also be better if you can take along a developer or a designer during your customer visits. They get to experience a slice of the customer's problems in person which would help a great deal in designing the right solution.
If you have other ideas related to this topic, please comment.
Monday, October 25, 2010
Product Camp - Bangalore Oct 23rd 2010
It didn't start out as expected, thanks to two flat tires our car ended up with. We missed out on the opening keynote since we reached the venue only at 11 AM. But the event turned out to be a very good experience. On Saturday, a bunch of people including me and my husband turned up at Yahoo! Bagmane Tech Park to participate in Bangalore's first product camp. Because of the delay, we could just catch up the last few points of the session by Vihari, Product Manager from Google. His topic was on product design. It was good to see that he recommended balsamic for low fidelity prototyping.
Key Take-aways from this session:
* One of his points was on cognitive walkthrough technique with customers. When you are showing a demo or conducting usability testing with customers on new product features/flow, ask this question - "Before taking action, what do you expect to see?" Were customers able to guess the flow as designed? This will provide good insights related to discoverability.
* "Keep desirability uppermost while balancing feasibility and viability". What makes a product (or a product feature) desirable for the end customer?
The next session that I attended was on "Designing for video experiences" by Supreet Singh, Microsoft. This was a completely new topic for me as I haven't read up much on video streaming. Though it was slightly more on the technical side, it was useful to learn on adaptive streaming and caching techniques.
I presented the first afternoon session on "product positioning". After the session, I got some good feedback and felt glad that a few people found it to be useful. Though I was presenting to an audience after a long time (almost a year ever since I completed my PGSEM at IIMB), I wasn't feeling nervous. I should thank my 4 year stint in Oracle Toastmasters for getting rid of stage fear. In terms of structure, I had planned out an outline a week in advance and prepared my content accordingly. After the session, I was thinking about areas where I need to improve in terms of my presentation skills.
* I need to have a lot more examples handy to illustrate what I'm trying to say.
* Shifting the discussion between the speaker and the audience could be much more smooth so the points conveyed by audience can be captured or repeated to the benefit of others
My presentation is available on slideshare. If you are interested, do check it out -
The last session was a panel discussion on social media, moderated by Amitoj Singh from Wipro. The panel brought out some interesting insights on accountability and ROI in social media initiatives.
* Rajesh from BrioTribes Technologies brought out an interesting point. For measuring accountability, the three actors involved in advertising are to be considered - brand owner, advertising enabler, customer
* On Privacy, Ganga from Yahoo! mentioned that next generations would care much less and so privacy will not get as much attention as it gets now. On attributing the customer's interest towards a brand, he mentioned about customers viewing branded display ads while they browse and the brand gets registered in their minds. When they are actually interested in making a purchase, they search in Google. So the attribution which led to customer's interest is not very clear in such cases.
* There were also some interesting questions which were discussed - Will social media replace print and TV? What is the worth of a Like?
It was a very useful and interesting Saturday, catching up with ex-colleagues, meeting new people and discussing ideas. Glad to see such forums are getting initiated. As a pleasant surprise, Yahoo! gave us all a bean bag to carry home !
Key Take-aways from this session:
* One of his points was on cognitive walkthrough technique with customers. When you are showing a demo or conducting usability testing with customers on new product features/flow, ask this question - "Before taking action, what do you expect to see?" Were customers able to guess the flow as designed? This will provide good insights related to discoverability.
* "Keep desirability uppermost while balancing feasibility and viability". What makes a product (or a product feature) desirable for the end customer?
The next session that I attended was on "Designing for video experiences" by Supreet Singh, Microsoft. This was a completely new topic for me as I haven't read up much on video streaming. Though it was slightly more on the technical side, it was useful to learn on adaptive streaming and caching techniques.
I presented the first afternoon session on "product positioning". After the session, I got some good feedback and felt glad that a few people found it to be useful. Though I was presenting to an audience after a long time (almost a year ever since I completed my PGSEM at IIMB), I wasn't feeling nervous. I should thank my 4 year stint in Oracle Toastmasters for getting rid of stage fear. In terms of structure, I had planned out an outline a week in advance and prepared my content accordingly. After the session, I was thinking about areas where I need to improve in terms of my presentation skills.
* I need to have a lot more examples handy to illustrate what I'm trying to say.
* Shifting the discussion between the speaker and the audience could be much more smooth so the points conveyed by audience can be captured or repeated to the benefit of others
My presentation is available on slideshare. If you are interested, do check it out -
Product Positioning
View more presentations from Anuradha Sridharan
The last session was a panel discussion on social media, moderated by Amitoj Singh from Wipro. The panel brought out some interesting insights on accountability and ROI in social media initiatives.
* Rajesh from BrioTribes Technologies brought out an interesting point. For measuring accountability, the three actors involved in advertising are to be considered - brand owner, advertising enabler, customer
- brand owner - The ads/creatives should talk about benefits customers actually get and shouldn't exaggerate.
- advertising enabler - Correct measurement of impressions or clicks
- customer - don't just complain about bad service. Also provide good feedback in case of good experiences
* On Privacy, Ganga from Yahoo! mentioned that next generations would care much less and so privacy will not get as much attention as it gets now. On attributing the customer's interest towards a brand, he mentioned about customers viewing branded display ads while they browse and the brand gets registered in their minds. When they are actually interested in making a purchase, they search in Google. So the attribution which led to customer's interest is not very clear in such cases.
* There were also some interesting questions which were discussed - Will social media replace print and TV? What is the worth of a Like?
It was a very useful and interesting Saturday, catching up with ex-colleagues, meeting new people and discussing ideas. Glad to see such forums are getting initiated. As a pleasant surprise, Yahoo! gave us all a bean bag to carry home !
Friday, October 8, 2010
Enrich your time as a product manager
Based on the points I put together for a presentation in the recent IIMB product manager's conclave, Bangalore
One of the best things about being a product manager is the number of activities one gets to work on in a day. Broadly, we can classify these activities into three categories – strategic, tactical and operational. All three categories are essential in solving market's problems and adding value to your target customers. What matters most is the percentage split a PM allocates in each of these categories in a given time period. There are no fixed guidelines on a percentage split that will work for a successful PM. But the more time a PM spends on strategic activities, he/she can create a bigger impact in the target market, thereby a bigger impact to his/her organization.
Observe how your time gets spent in a week, consciously noting down the different tasks/activities that occupy your time - the interruptions, context switches, phone calls, emails, meetings, casual discussions, status updates, ideation, brainstorming etc. Group your time under the three different categories and compute your percentage split of strategic, tactical and operational activities. If your strategic percentage is higher compared to the other two, you are doing an excellent job. For the rest of us, we have work to do to reallocate the percentages.
First, see if you will be able to delegate the operational activities to business operations and technical sales support teams. If initial handholding is needed, give the required support but eventually they should be able to take care of customer complaints and issues independently. For tactical activities such as product demos and requirements review with stakeholders, requirements prioritization and bugs triaging, allocate a fixed time in your calendar preferably the time of the day when your ideation or thinking hats would like to take a break.
As a product manager, one has to constantly keep abreast of the market situation, industry updates, competition growth and developments in related industries. These would give you useful insights which would help you plan your product roadmap. Subscribe to relevant blogs and news articles and ensure you catch up on reading on a regular basis. Setup 30 minutes in your calendar exclusively for catching up on these blogs everyday. Most importantly, to plan a high impact product roadmap, interfacing with customers preferably face-to-face or at least over the phone will give you a better understanding of their pain points and how your product is solving or not solving those pain points for them.
With inputs coming from all these different sources, it is important that you spend some uninterrupted time with yourself, interpreting these different inputs and brainstorming on how you can evolve your product in the next few months. I have found timeboxing / Pomodoro techniques to be very useful to ideate or brainstorm within a specific box of time.
I hope some of these points are helpful in enriching your precious time as a product manager and launching awesome market oriented products.
Monday, May 17, 2010
User Personas
Having touched upon the idea of integrating user behavior into the product design in the previous post, let me explore further on this topic. One of the approaches that I have found to be very useful is this idea of "user personas".
By trying to build a persona, one gets to understand the intricacies of the user behavior. This provides valuable inputs that can be fed into the product design.
A user persona is a mechanism to understand the potential users of your product or service. The idea of a persona derives more from the behavioral and psychographic aspects of the users.
In order to build a user persona, explore the following questions:
* Who is my customer?
* Where does he live?
* What does his typical day look like?
* Whom does he interact with on a typical day?
* What motivates him to do something?
* What irritates him the most?
* What is his typical personality?
* Is he intrinsically or extrinsically motivated?
* Under what circumstances does he feel the pain point that you are trying to solve?
* What are the after-effects when he faces the pain point that you are trying to solve?
It helps if you can build a story around this user by giving a fictitious name and articulating his environment. You can also come up with hand sketches and drawings to illustrate the personality of the user of your product idea. This can provide useful and interesting inputs to your design and engineering teams.
If your product or service is catered to different market segments, build a user persona that represents each of these segments. Highlight the difference in the behaviors of these different users.
The best time to take up this persona building activity is just after you are done with segmentation of your market and just before you formulate the product strategy. With segmentation in place, you will exactly know which markets to target and depending on the target segments, whether the personas will be different. After you have the personas clearly defined, it will be much more easier to think about your product roadmap and the needs you will address for your target segments.
For more information on personas, check out these blogs:
http://www.buyerpersona.com/2010/05/how-kristine-developed-a-great-buyer-persona.html
http://carsonified.com/wp-content/uploads/2009/10/personas_final_b.jpg
http://bonfireda.com/docs/The-Power-of-the-Persona.pdf
http://www.savvyb2bmarketing.com/blog/entry/580831/getting-back-to-the-roots-of-buyer-personas-interview-with-tony-zambito-of-goal-centric
By trying to build a persona, one gets to understand the intricacies of the user behavior. This provides valuable inputs that can be fed into the product design.
A user persona is a mechanism to understand the potential users of your product or service. The idea of a persona derives more from the behavioral and psychographic aspects of the users.
In order to build a user persona, explore the following questions:
* Who is my customer?
* Where does he live?
* What does his typical day look like?
* Whom does he interact with on a typical day?
* What motivates him to do something?
* What irritates him the most?
* What is his typical personality?
* Is he intrinsically or extrinsically motivated?
* Under what circumstances does he feel the pain point that you are trying to solve?
* What are the after-effects when he faces the pain point that you are trying to solve?
It helps if you can build a story around this user by giving a fictitious name and articulating his environment. You can also come up with hand sketches and drawings to illustrate the personality of the user of your product idea. This can provide useful and interesting inputs to your design and engineering teams.
If your product or service is catered to different market segments, build a user persona that represents each of these segments. Highlight the difference in the behaviors of these different users.
The best time to take up this persona building activity is just after you are done with segmentation of your market and just before you formulate the product strategy. With segmentation in place, you will exactly know which markets to target and depending on the target segments, whether the personas will be different. After you have the personas clearly defined, it will be much more easier to think about your product roadmap and the needs you will address for your target segments.
For more information on personas, check out these blogs:
http://www.buyerpersona.com/2010/05/how-kristine-developed-a-great-buyer-persona.html
http://carsonified.com/wp-content/uploads/2009/10/personas_final_b.jpg
http://bonfireda.com/docs/The-Power-of-the-Persona.pdf
http://www.savvyb2bmarketing.com/blog/entry/580831/getting-back-to-the-roots-of-buyer-personas-interview-with-tony-zambito-of-goal-centric
Sunday, April 25, 2010
User behavior and product design
I use a Yahoo! mail account for my personal emails and I have subscriptions to many group emails. Over the past few months, my mailbox has been overflowing with many unread emails as I tend to scroll through the list and read only the most important ones at the beginning of my day. I have unsubscribed from many group lists to keep the incoming information under control. However there are some groups in which I might get a few important messages occasionally which I do not want to miss out. So I decided to create a few filters and organize my inbox.
This is exactly THE time in the lifecycle of product-user interaction when one starts to think about filters in a mail product - when there is a bunch of unread mails and the user feels that it is getting unmanageable and wants to get organized; not when the time he/she creates a new mail account and immediately starts to create filters.
Coming back to my problem, I located the "Filter emails like this" and created a filter. So far, so good. But to my utter disbelief, I couldn't see the "run filter" or similar such option. I wondered if this feature was hidden somewhere that it wasn't evident to me. After googling for a bit, I found out that such a feature doesn't exist in Yahoo! mail. Disappointed with the lack of this feature, I dropped the effort of organizing my inbox.
This experience triggered a thought process of how one should go about integrating user behavior into the product design. Before designing a product's feature or even a minor functionality, ask yourself these questions -
1. When will my user explore this specific functionality?
2. What are the circumstances under which this particular feature will be used?
3. What is the motivation factor that will enable the user to try out this feature?
Evaluate the physical circumstances (place of usage), the psychological state of the users (positive or negative frame of mind) and the expected outcome (not only from a product point of view but also from the user's intended action).
More to follow on this topic.
This is exactly THE time in the lifecycle of product-user interaction when one starts to think about filters in a mail product - when there is a bunch of unread mails and the user feels that it is getting unmanageable and wants to get organized; not when the time he/she creates a new mail account and immediately starts to create filters.
Coming back to my problem, I located the "Filter emails like this" and created a filter. So far, so good. But to my utter disbelief, I couldn't see the "run filter" or similar such option. I wondered if this feature was hidden somewhere that it wasn't evident to me. After googling for a bit, I found out that such a feature doesn't exist in Yahoo! mail. Disappointed with the lack of this feature, I dropped the effort of organizing my inbox.
This experience triggered a thought process of how one should go about integrating user behavior into the product design. Before designing a product's feature or even a minor functionality, ask yourself these questions -
1. When will my user explore this specific functionality?
2. What are the circumstances under which this particular feature will be used?
3. What is the motivation factor that will enable the user to try out this feature?
Evaluate the physical circumstances (place of usage), the psychological state of the users (positive or negative frame of mind) and the expected outcome (not only from a product point of view but also from the user's intended action).
More to follow on this topic.
Subscribe to:
Posts (Atom)