Posts Tagged “Documentation”
People, people…please calm down. I know that it’s been more than a month since the last Product Management Question Corner, but these things take time. Fortunately, this one is worth the wait! This edition of the Question Corner brings us Rene Larro, VP of Products and Solutions Marketing at Model N, a provider of revenue and compliance management software. Rene brings us the perspective of a Product Manager who started out as a traditional consultant and rose through the ranks of Product Management all the way to the VP level.
Q: How did you come into the role of Product Manager and was it planned?
A: Moving into Product Management wasn’t specifically planned, but throughout my career I’ve always been drawn to roles where I could be involved with both business and technology. In 1999, I made the jump from consulting to the startup world and joined Digital Impact as an Account Manager. At the time, DI was building out it’s second generation campaign management tools and I had the opportunity to work with the Product Management team as an internal beta user for one of our products. I was constantly talking with the Product Manager about things that “I thought the software could do better”. The more we worked together throughout the release cycle, the more I became interested in the role. When an opportunity came up to move into Product Management I jumped at it and have been in Product Management and Product Marketing ever since.
Q: What are the biggest challenges that Product Managers face?
A: One of the biggest challenges you face as a Product Manager is balancing the needs of your company as a business and the demands of your customers when making decisions about the roadmap and tradeoffs for a given release. New license sales are the lifeblood of an enterprise software company, and to successfully grow the business you need to continuously add new products to your portfolio to give you new things to sell. But, the more successful you are and the larger your customer base grows, there are increasing demands to add additional features and functionality to your existing products to keep your installed base happy. Your existing customers don’t always care about the great new product you’re bringing to market next year, they want you to focus on their issues, and to add their key features to the roadmap. There is never enough time or resources to do everything you want to do. It’s a delicate balance and there are always hard tradeoffs to make.
Q: What have you done or what would you consider the best way(s) for Product Managers to improve themselves?
A: There are a few things that come to mind.
Get to really know your customers and the problems they are facing. You can’t be a successful product manager by sitting in your office. Get on the road, visit your customers, talk to them and sit with them while they use your products. I’m always amazed at the insights I get by sitting with users and watching them do their jobs. Customers love the attention, and truly appreciate it when Product Managers visit and listen to them. And sometimes, the simplest change in the app can turn a frustrated user into a champion.
Get to know your product and your technology inside out. The most successful product managers I’ve worked with become experts in their products, what they do, and how they are built. Great product managers develop a “feel” for what it takes to build their apps, and how their apps fit in with all the other pieces of their technology. Don’t be afraid to get into the details. You’ll get more respect from your engineers, you’ll be able to make better tradeoffs on effort vs. benefit, and ultimately make better decisions about your products.
Finally, get into the field and sell. Designing and delivering the best product in the world doesn’t mean anything if it doesn’t sell. At the end of the day, sales drives the business. If you want to be a real asset to your company, get out with the sales team and learn what works and doesn’t in the sales process.
Q: Where is the best place for the Product Management function in an organization and why?
A: For an enterprise application company, I’ve always believed that Product Management needs to report into the business, not to engineering. It’s easy for Product Mangers to get wrapped up in the day-to-day aspects of the internal side of the role. Reporting into the business helps ensure balance between the demands of building the product, with the necessity of ensuring the product is marketable and can be sold.
Q: If someone told you that they wanted to be a Product Manager, what would you tell them?
A: If you like working on challenging problems, want to be doing something different every day, thrive on being thrown into challenging situations, want to do both strategy and tactics, love getting into the details, and want to make a real difference in your organization, Product Management is a great role to be in.
I think it’s the most demanding job in a software company, but it’s also extremely rewarding. There is nothing better than slaving away on a product for a long period of time, seeing it go out the door, and then sitting down with users and watching them run their business with what you built.
Q: What is your greatest Product Management achievement?
A: Building a $50M enterprise software company from the ground up and having a product that has continued to sell even in an impossibly tough economy. Starting with just a technology platform in 2001, my team was responsible for defining and building an integrated application suite that now contains 12 applications, and is used by over 30 major Life Sciences companies across the pharmaceutical, bio-tech, and medical device segments to manage more than $80B in revenues.
_________________
And now for Rene’s question for The Productologist:
Q: What’s your opinion on the age old question of Product Marketing vs. Product Management. Should Product Managers own both sides, or is it two different roles?
A: What a poignant question given that I recently took a new position as Director of Product MARKETING. There has always been a blurry line between Product Management and Product Marketing. Depending on the company you are working for, these could be the same job, overlapping jobs, or completely different jobs. The complexity around this issue has been discussed at length on many Product Management blogs and in Product Management training classes.
The factors that determine if one person can do both Product Management and Product Marketing are numerous:
- size of the company
- maturity of the company
- sophistication of the product(s)
- number of products
- other available marketing resources
- comfort with talking to the field (Sales, Customers, Prospects)
- comfort talking with outsiders (analytst, media, board members)
- ability to balance more on your plate than you have room for
In my eyes, Product Management and Product Marketing are not the same, though they share some commmon goals and tasks. The skills necessary to be a great Product Manager and a great Product Marketer are not often found in the same person. Product Managers benefit from technical skills, relationships with/respect from Engineering, project management, and the ability to communicate effectively with internal and external constitents. They have to know the ins and outs of their products and be able to help the field identify how to tackle customer and prospect challenges.
Product Marketers are much more externally focused. They get out and evangelize the products. They work with customers, prospects, the field and oustiders to understand the market and set strategy for how to serve the market.
It’s hard to envision a single person who can do all of that and do it well. in most cases, they don’t. We all have strengths and weaknesses. We find way to compensate for our weaknesses. We get our favorite SE to do the really hard technical demos. We ask for help from someone in finance to help with our excel spreadsheet models. We get help from the PR specialist when we need to write up snazzy content for a presentation. We ask Technical documentation to explain (one last time) whether the API can do what we told the customer it could do.
Even if there are people out there who have the skills necessary to do both jobs, if you combine those two roles, that’s a lot of work to accomplish and you have to ask yourself if it is realistic for them to do all of those things. Can one person do all of that? Maybe, for a short period of time.
Many of us have been there before. Sixteen-hour days, seven days a week (well, maybe only 10 hours a day on weekends). It’s exciting at first, but after a while, it begins to grate. You start choosing your battles. You pick the ones that feel most comfortable. The ones that don’t find themselves at the bottom of a growing to-do list.
Can one person be both Product Manager and Product Marketer? Yes. They can even be successful if the requirements of the position and volume of work match their capabilities and capacity. But the reality is that in a mature organization with a complex product (or suite of products), the combined role is more than one person can reasonably handle.
A bit more about Rene:
Rene is the Vice President of Product and Solutions Marketing at Model N. Model N is an enterprise software company that provides Revenue Management solutions to Life Sciences and Hi-Tech manufacturers. He’s been with Model N for eight years and through that time has played numerous roles in various aspects of Product Management, Product Marketing & Pre-Sales. Rene was the original Product Manager in Model N’s Life Sciences Business Unit and was instrumental in driving the direction of Model N’s product suite and building the Product Management organization. Prior to Model N he was a Product Manager at Digital Impact, a Manager at Andersen Business Consulting, and he started his career as an Actuarial Analyst in the insurance industry. Rene has an MBA from the University of Michigan, and a BS in Managerial Economics from UC Davis.
Popularity: 3% [?]
Related posts
Tags: beta, career, Customers, Documentation, enterprise software, Marketing, MBA, product management training, Prospects, release cycle, requirement, roadmap, Sales, strategy
No Comments »
I have recently been embracing the change from traditional waterfall product development to an Agile framework. In the past, I have been wary of Agile, especially for enterprise products, but as I gained a better understanding of the Agile principles, I started liking it more. There are still caveats for using Agile methods and success of Agile process depends heavily on the staff managing the framework, but I am starting to see why Agile development is so appealing.
From a Product Management perspective, one of the most appealing aspects of Agile is how requirements documentation works. For many years, I spent a ridiculous amount of time creating requirements docs (primarily MRDs, but also some PRDs and TDDs). The reason for this is that MRDs have a broad audience. The same MRD that Developers and QA Engineers use to build their functional requirements also has to be read, understood, and digested by folks from the Sales, Support, Pro-Serv, and Marketing.
That means MRDs are chock full of data which can include some or all of the following topics:
- Business Case
- Revenue Model
- Competitive Analysis
- Market Analysis
- Feature Descriptions
- Feature Design
- Staffing Requirements
- and the kitchen sink
All of this data makes for a large and cumbersome document, both to create and to absorb. On more than one occassion, I have had to chase down folks who insisted on getting a copy of the MRD (and who promised to provide feedback), only to find that they had not even read it 3 weeks after I sent it to them (and sent out multiple reminders).
Ugh. A lot of work with little or no benefit.
What I like about Agile development is that most of the extra “fluff” is moved out of the requirements process. It’s usually still there in the release cycle, but it’s someplace else, like a hallway conversation with your CEO, or a presentation to the exec team, joining the Sales/Support team’s weekly staff call, or an on-going discussion with your manager. Those are the folks that care about the fluff part of requirements docs.
When you work with the Dev team, for the most part, they don’t care about the specifics around revenue, competitor analysis, or anything else not directly related to helping them write the code. That’s not to say they don’t care at all. Revenue should be very important to ALL employees, but as information that Developers need to do their jobs, those things just to add much value.
So, instead of a 30-page MRD, I like the 5-10 page release specs doc. I focus on what is in the release and what it should do. I usually add a bit about what problem it solves or how it would be useful so that the Dev team can use that information to better understand the requirement, but not much more than that.
To be honest, the short-n-sweet option doesn’t always work out as well as I would hope. It still requires having some lengthy discussions with Developers to iron out issues, but I’d have to do that with the big MRD, too, so why not save time and not write it, and then focus on getting the software built and into the hands of testers and users?
Less work for the Product Manager, which means more time to get out into the field, spend time with customers and partners, and listen to folks explain how I can help them with my product. Everybody wins!
Popularity: 4% [?]
Related posts
Tags: agile, agile development, agile methods, business case, competitive analysis, customer, Customers, Documentation, Engineering, feature descriptions, feedback, functional requirements, Manifesto, Marketing, MRD, product management, QA, release cycle, requirement, revenue model, Sales, Support, users, waterfall
6 Comments »
The Art of Product Management by Rich Mironov
I received an early copy of Rich Mironov’s The Art of Product Management, which is a collection of some of his earlier articles from his newsletter, Product Bytes.
I’ve met Rich a few times at SVPMA events and had some good conversations with him before going in to hear the featured speaker. I’m also a subscriber to his newsletter, but I hadn’t read any of the vignettes that were selected for the book.
The Art of Product Management is a lot like a book of poetry. The content is short and sweet and divided into bite-sized morsels. It’s not meant to be consumed in one session, but rather over many sittings and discussed as you go.
The chapters in The Art of Product Management are grouped together into sections along the lines of a parenting book (a metaphor that they author introduces in the preface), but truth-be-told, it’s a pretty loose organization. The original publication dates of the stories are not chronological and you can hear how Mironov was in different places professionally in the different posts. I liked this element of the book because it didn’t feel like he was this “all-knowing” Product Management expert who was casting his immense knowledge down to the masses.
The book is a how-to guide for Product Managers, but not in the traditional sense. Miranov doesn’t list the 7 things every Product Manager needs to have in their requirements documentation or provide sample schedules for executing a flawless Beta program. Most of the information presented is in form of “Hey, this happened to me and now I know better. I thought you would be interested.”
And it’s geared primarily toward folks who work at software start-ups, which is good, because most other Product Management books are squarely set on addressing the needs of formalized Product Managment teams at big companies. Anyone who has worked at a small startup company can tell you that while it’s a good foundation to have, you just don’t use most of the formal Product Management processes at small companies.
Another aspect that I liked about the book is that it is purely anecdotal. There are no longitudinal studies, surveys, or secondary analysis, just the author’s experiences. And the topics range from those specific to Product Mangement (“Null Service”, “Insider Thinking”, “What’s Your Pricing Metric”) to ones that are tangential, but still interesting (“Early Selling”, “Why Are There Serial Entrepeneurs”, “Girls Getting a Head Start(-up)”). With this type of setup, the reader gets to decide how valuable the information presented is to them.
RECOMMENDATION: I liked The Art of Product Management. It was easy to read and it was easy to recognize some of my own product and business challenges in the stories the author tells. I wouldn’t recommend this as the first book to pick up as a brand new Product Manager, but I would say that it is a good option for those who are 12-18 months into their first Product Manager role. It’s also a good option for more senior Product folks as both a refresher and an enjoyable trek down memory lane (“Oh yeah, I remember doing that, too!”).
Popularity: 30% [?]
Related posts
Tags: beta program, Book Review, Documentation, longitudinal, new product, newsletter, organization, PMA, pricing, product management, product management books, requirement, Rich Mironov, start ups, Startup, SVPMA, vignettes
3 Comments »
 I saw a question on Linked In from a new Product Manager who is switching careers and wanted some pointers about how to make the transition smoothly. I answered the question with some suggestions. She is not a software Product Manager, as I am, so my response to her was not tied specifically to what I do as a software PM. I am re-posting a slightly modified version of my response here. Enjoy!
<original_response>
Welcome to Product Management. It’s a very challenging and rewarding field and provides a great opportunity to interact with many business functions.
I work as a software Product Manager, which is slightly different than what you are doing, but regardless, ANY Product Manager should be doing the following things to be successful:
- Learn about your product(s).
Even if you are already familiar with them, do whatever you can to learn more. Review documentation, go to user training, talk to any “experts” within your organization about what they know about the product.
- Listen to stakeholders.
Product Managers are the link between many different areas of the business. You will need to take those diverse and frequently conflicting interests into account as you make product decisions. Product Management is not a democracy, but it does require listening to, understanding, and synthesizing input from many different constituents.
- Listen to users.
Every product or service has a user. It may be an external customer or an internal one. The Product Manager is the proxy for that user and all users. To effectively be that proxy, you need to listen to feedback from users, both positive and constructive. Don’t let others (Sales, Support, Executives, etc) be a filter. You have to hear for yourself.
- Understand your business.
Beyond just making your own product successful, you need to know how your product fits into the overall corporate strategy and what the success factors for the company as whole are. Your decisions need to take those external factors into account.
- Make decisions holistically.
Product Management is a long-term process and you will be faced with making many decisions almost every day. As you weigh the details of each situation, focus on how that decision will affect your product over time. The shortest, easiest option may look appealing, but also consider what that decision means for the future. Also consider that each decision is not made in a vacuum. Try to see how those decisions are linked together.
- Take risks and embrace failure.
No one does everything right every time. Even with the best planning and analysis, things don’t turn out the way you think they will. Don’t be afraid to do something just because it might not work. If it’s not successful (or as successful as you thought it would be), figure out why and learn from it. A past manager of mine told me once that it is OK to make many mistakes, but not the same mistake more than once.
There is so much to Product Management that it is hard to sum up in short space and this is by no means an exhaustive list, but it should help make the transition a little easier. Some of the information you need to be a successful Product Manager only comes with experience and getting your hands dirty.
</original_response>
One thing I left off of my original response (because she was already doing it to some degree) is to talk to other Product Managers. Success as a PM in one organization does not guarantee success in another, but there is a lot of collective knowledge out there. Search out and use that knowledge to jump from rock to rock as you cross the river, rather than wading across on your own.
For starters, check out the other Product Management blogs I have listed in my blog roll on the right panel (look for the heading: BlogNation). They know a lot about a lot of PM topics. Just ask. They won’t bite.
Popularity: 61% [?]
Related posts
Tags: business functions, conflict, corporate strategy, Customers, Documentation, external factors, feedback, process, product decisions, risk, Sales, software, stakeholder, strategy, success factors, Support
5 Comments »
 I had another visit with one of my customers the other day (I know, I’ve been writing a lot of posts about customer visits, but they are important and I learn a lot from them). I call them MY customer, because they are using a product that I am responsible for. It’s important to view yourself as one of the “owners” of the customer because as the Product Manager, you are responsible for their satisfaction, currently and in the future. If you are not getting out into the field to talk to your customers, both satisfied and frustrated ones, then you are missing out on valuable feedback on how to improve your product.
This particular visit was coordinated by our Account Executive at the request the VP of Engineering. He (the VP) wanted to talk to technology-savvy customers and invited me along, as I have been pestering just about everyone to go with them on customer and prospect calls.
The purpose of the discussion was two-fold:
- A knowledge exchange about each of our product roadmaps and how the customer plans to use our product
- The opportunity to hear first hand about some of the challenges (and successes) that the customer has had with the product
Part 1 was pretty straightforward. They presented the overview of their operations and how they planned to integrate our product. I then gave them a view of our product roadmap.
I call it a view, because when I present the product roadmap to customers and prospects (under NDA, of course), I don’t show them the raw version that I use to prioritize and work with Engineering on. Not because I have something to hide from them, but because for folks who are not intimately involved in the roadmap process, there is a lot of noise in the document that would likely cause confusion and/or would not be useful. There is also some customer information in it that I use for tracking purposes that I don’t feel comfortable sharing with other customers, even under NDA.
The view that I let them see is one that highlights features and capabilities with a long view. The goal is not to show them what is in any particular release, although I do share what is going in to the current and next major releases, but rather the long view.
The long view is a window into where the product is going. For an enterprise infrastructure product like mine, that means identifying how customers are going to be using the product over the next 4 years because unlike software or Web services, they are not likely to abandon the purchase without a truly significant reason.
Our customers don’t say, “We like your product, but a competitor of yours has a new feature/lower price/new UI, so we are switching.” Instead, they say things like, “We paid $X for your product and we expect it to be able to do Y” or “We like the core feature set of the product, but we plan on doing X in the future and we want the product to enable/support that.”
To answer inquiries like that, I have to be able to show them where my product is going in the future. I use the roadmap as a tool for communicating that with them. As part of that discussion, I can solicit the prospect or customer on what they view as important, which helps me understand their real-world needs.
Part 2 of the discussion involved listening to their problems with my product. As easy as it sounds, this is a challenge for many Product Managers. Product Managers are sensitive to criticism of their product (I’m as guilty of this as the next PM). We instantly try to frame any problems as “workable,” by which I mean that we try to identify ways that the user could achieve their goal within the current product framework. This sometimes helps in the short-term, but it precludes you and the customer from thinking about the real solution.
Instead of trying to whitewash the situation, a technique that I use is one that I learned back in grad school when I was studying Counseling Psychology–Active Listening. This suite of listening skills allows you to be more engaged in hearing what the other person is saying rather than debating points back and forth. It is very validating for customers when you, as the Product Manager, just acknowledge the issue that they are having and listen to what they have to say about it.
Lack of defensiveness on the part of the Product Manager creates an environment where the customer is more likely to provide you with valuable input, because they don’t have to waste time and effort in arguing their point.
I won’t kid you, it’s a LOT HARDER than it sounds and the first few times you try it, it’s not only painful, hearing all of that “feedback,” but it takes a lot of effort not to respond. But, I promise that if you keep at it, you will get so much great information that you can use to improve your product that you’ll wonder how you ever collected any useful user feedback without it.
Popularity: 59% [?]
Related posts
Tags: challenges, communicate, customer, Documentation, feature, feedback, knowledge exchange, Prospects, roadmap, satisfaction
2 Comments »
It’s been a little over a month since I started using this new note-taking method and I wanted to provide some details on how it’s going for me. To be honest, it hasn’t been as easy to switch to this note-taking style as I thought it would be. I have struggled on a few fronts–
Paper
The Cornell Note-Taking Method utilizes a special paper layout that divides the page into discrete sections. Each of the sections has a specific purpose. In my original post on this topic, I provided some links to Cornell Note-Taking Method page generators, but I found that to be a bit wasteful. I didn’t see the need to use a whole page of paper (even recycled paper) for every meeting so I decided to use my existing notebook (one of those bound composition notebooks with the black and white cover that you see in the school supplies section at the store) and just create the Cornell Note-Taking Method layout manually using my pen.
This has worked fine, except that I still end up wasting a lot of paper because I don’t end up taking a full page of notes every time. I’ve even had the occasion to cross out the original meeting title and write a new one because I didn’t write anything down.
Space
Using the Cornell Note-Taking Method, I sometimes find that I feel cramped when I write ideas down. Because the note-taking area is smaller than without the Cornell Note-Taking Method, I find myself running out of room on the page faster. I also find that it seems harder to write down a complex thought with less space. It’s nice to have the other areas to write additional or clarifying notes in, but sometimes it ends up being wasted space if I don’t use it.
Reverting
Another challenge that I have had is that it’s quite easy for me to forget to use the Cornell Note-Taking Method and go back to my old style of note-taking. I usually notice this about 1/4 to 1/2 of the way down the page. I don’t know if I just need more time or if breaking the habit of my old style is just going to be a challenge I will face for a long time.
Time
Part of the Cornell Note-Taking Method is going back over the notes that you have written and re-stating or summarizing them to better ingrain them in your memory. I have found that due to my schedule (lots of scheduled and impromptu meetings and phone calls), I don’t have or take the time to go back and do the secondary note-taking steps. I do give my notes a cursory once-over to look for action items or things I need to follow up on, but as for summarizing all of the days notes, that just doesn’t happen.
Next Steps
I’m going to keep trying the Cornell Note-Taking Method for a while longer to see if I can get over the hump of my past note-taking habit and see if there is a bump in usefulness/productivity for me, but I thought it would be easier to switch to using the Cornell Note-Taking Method and the benefits would be more pronounced.
Popularity: 88% [?]
Related posts
Tags: breaking the habit, cornell method, cornell note taking method, diagrams, Documentation, meeting minutes, meetings, note taker, note taking, process, productivity, staff meeting, tips and tricks
3 Comments »
I’ve been listening to career-related podcasts on my commute to and from work lately and one of my favorites is Manager Tools. They are basically two management consultants (Mark Horstman and Michael Auzenne) who talk about tips and tricks to being a good manager, which if you have supervised others at work, you know is not as easy as it seems.
One of the “casts” (that’s how they refer to the individual podcasts) dealt with running meetings, a topic that I have discussed previously. They highlighted the fact that as the meeting leader, you should not be trying to manage the documentation of the meeting because your role is to facilitate and if you are struggling to write things down, you aren’t focused on moving the discussion forward. They say you need a dedicated note-taker to transcribe the discussion.
That sounds great when you are having a daily, weekly or monthly staff meeting and all of the participants in the meeting are your direct reports and you can easily delegate the responsibilities of note-taker to someone on your team, but in my world, the majority of folks that I have meetings with (when I am the meeting organizer) are either peers or senior to me. I can’t just say, “You there, VP of Engineering. Please take notes during this discussion and distribute them to everyone present by the end of the day.” Well, I could, but it’s not likely that I would leading many more meetings (or anything else) at that company soon after.
So, it’s up to me, which brings us back to the podcast about meetings. Another recommendation that the folks at Manager Tools make is that the note-taker use something called the Cornell Method of Note-Taking. This piqued my interest because for as long an I can remember, I’ve never used a “method” for taking notes, either in school or in a business setting, although I’ve most likely been using some form of outline notes, since I tend to try to organize the notes into a hierarchy as I am writing them.
During the podcast, Mark and Michael described the Cornell Method at a high-level and explained that there is a process for how you write the notes and what you do with them afterwards. The process involves dividing the note page into discrete sections that each have a unique function. There’s a notes, cues and summary section which are broken out on the page roughly 60/20/20.
The details of the discussion are written in the notes section and are distinct items that you hear in meeting. The folks at Manager Tools identify these as the who-what-when elements. Whenever you hear one of those things in a meeting, write it down in the notes section.The cues area is for supplemental notes that tie details together, diagrams or questions for follow up. In the Cornell Method, which was originally designed for college students, the cues are to be written after the lecture or chapter is completed and you have finished writing in the notes section, but for business notes, it makes more sense to use this area for alternative content such as organization charts, workflow diagrams or mindmaps.
Lastly the summary section is for capturing next steps, action items or surprise, surprise–a summary.
The benefit of this whole process is to help with the absorption of the information. In an educational setting, it helps students better understand and remember the information that they hear in class and read in their texts. The steps of capturing, reviewing and re-writing the notes in various ways helps to ingrain the content in their memory and gives them ways to assimilate the information together into their body of knowledge.
For business users, it provides a mechanism to capture different types of information in an organized way, even if the information is not presented in an organized fashion. The challenge of many meetings, especially at software companies and at startups in particular, is that the discussions in meetings are non-linear. They don’t move from topic to topic gracefully. They are more like a teenager trying to learn how to drive a car with a manual transmission in a parking lot. They lurch and stop and change direction and sometimes just go around in a circle. The Cornell Method could be a better way to capture all of the information, digest it, and make it easier to distribute to others.
Now, after having gone through all of that, I have a confession. I have NEVER used the Cornell Method. But, I am anxious to try it out. I have been doing some research on it and there are some online wizards that can help you make the templates for Microsoft Word or PDF. I plan to just manually divide my current notebook pages to save some trees, but I know that others prefer to have task-specific tools and I don’t begrudge them that choice.
If you have experience using the Cornell Note-Taking Method (or other similar methods) in either an educational or business environment, I’d love to hear what you like/dislike about it. I’m excited to try it out for myself.
(Note page layout image: University of Maine at Fort Kent)
Popularity: 82% [?]
Related posts
Tags: cornell method, diagrams, Documentation, meeting minutes, meetings, note taker, note taking, process, staff meeting, tips and tricks
3 Comments »
Today, my own advice worked…for me. I went to visit a customer with some other team members to hear feedback from the customer about their experience with my product and hear some of their enhancement requests. I tend to over-prepare for these types of visits where I end up bringing a lot more than I need (everyone else on my team just brought a notebook and pen), but today it turned out that my over-preparedness paid off.
I wrote earlier that it’s a good idea to bring along a thumb drive in case you need to transfer files. I also carry around an extra (my company gives them as tchochkies) that I can give out if needed.
On the customer visit, it turned out that they were not running the latest version of the product. I discussed improvements in the latest release that would address some of their issues and concerns with the version that they were currently running. I was able to give them copies of the release notes for the latest release, which highlighted the new features and lists the bugs fixed since the last release.
I just pulled out my spare thumb drive, copied the files from my laptop and handed it over to them. Now, the customer not only has a good feeling about our ability to quickly respond, they have a physical reminder of the experience.
Later on in the meeting, we discovered that the customer was a bit overwhelmed by all of the features (I haven’t heard that complaint for this product before). I captured the enhancement request to have a quick-and-dirty way to move through the workflow if the user only wanted to use the minimal requirements, but we also learned that the customer was not very familiar with the product documentation.
I asked for the thumb drive back and had one of my co-workers copy a MS Word version of our quick-start guide on to it so that the customer could review it and also use it to create a pared down version to suit their process. Two issues resolved while on-site with the customer!
Now, granted, I could have done the same thing by emailing them the files when I got back to the office, but would that have had the same impact?
Popularity: 30% [?]
Related posts
Tags: customer, customer visit, Documentation, enhancement, feedback, meeting preparedness, thumb drive
1 Comment »
In a post I wrote back in March [Hiring for Success], I discussed the importance of finding and hiring great Product Managers. But in the same way that great workers can be a boon to your organization, poor performers can drag you down. Not only do they create more work for others on the team, but they can poison the atmosphere and cause other members to become frustrated or leave.
“When they (managers) finally decide to get rid of the under-performing slob who plays PC solitaire all day in her cubicle, it can be surprisingly tough to do. And that, in turn, affects productive workers. Few things demotivate an organization faster than tolerating and retaining low performers,” says Grant Freeland, a regional leader in Boston Consulting Group’s organization practice.
The quote above comes from the cover article in this week’s BusinessWeek, “Fear of Firing” which talks about how difficult it can be to fire under-performing staff due to the risk of costly litigation. The author describes several cases where companies were sued and lost because they terminated an employee who felt that they had been discriminated against, even though the employer had documentation verifying that the employee’s performance had been weak or that they were demoralizing to other employees.
Now, don’t get me wrong, I wholly support anti-discrimination laws in the workplace and elsewhere. There has been a long history of discrimination (workplace and otherwise) in the U.S. I am a strong believer in the value of diversity in the workplace, which includes hiring staff with different perspectives, backgrounds, training and experience.
The more diversity on your team, the more likely you are to come up with creative solutions to challenging problems. The problem is that for all of their promise for equality, anti-discrimination laws can be abused and it is difficult and costly to defend against discrimination claims in court.
Unfortunately, what this means is that in order to protect themselves against such claims, companies are becoming fearful of terminating any poor-performing employee who is not a white male under 40, and even employees in that group can be considered victims of reverse discrimination.
So, what does a Product Manager (or any manager with subordinates) need to do in order to remove poor-performing and/or destructive staff while still protecting themselves and their company from litigation. Here are some key things to do and consider if you are looking to unhire someone.
-
Talk to the person
It’s not fair to terminate an employee if you never gave them a chance to rectify the problem first. Whether you are a peer or a manager, don’t be afraid to discuss a performance issue with the individual first. It can be uncomfortable, but flip the coin over and envision how you would react to the same information if it were being presented to you. Wouldn’t you want to know and have the opportunity to correct the situation?
-
Documentation
As soon as you start noticing a problem (or problems), start to keep track. A detailed accounting of consistent will help back up your concerns when you move to step 3 and will allow you to provide specific examples to the individual when you (or their manager) talks to them about the issue.
-
Get HR involved
Many managers don’t think of HR as an ally, but in this and many other situations, your HR team can make the process less painful for everyone. They are considerably more experienced with personnel issues than most managers and can help keep the process in line with corporate policies and local/state/federal laws. They can also provide support to you as the manager or peer on how to effectively address the issue/individual. HR is also an important part of item 2.
-
Be quick
Don’t let performance or personnel issues fester. They can have long-lasting effects on the team even after the issue has been resolved. For example, if it takes a long time to address a problem, the team may lose confidence in you (or the person responsible for resolution). Team members may be so frustrated that they start to look for another job.
-
Be concise
When you finally get to the place where you have to fire someone, be brief. Explain the situation and how the process will work. The decision is made; don’t get tied up in a discussion about what the individual can do to fix the problem. Be prepared for the individual to be emotional, but don’t let yourself get caught up in it. Here’s a checklist to help you make sure that you take care of what is necessary.
-
Don’t make it personal
There is NOTHING personal about firing someone. Performance, disruptive behavior, headcount reduction due to business conditions–these are legitimate reasons for letting someone go. If you find that your reasons do not fit into those categories, then you should re-evaluate whether you a being truthful about your criteria for terminating the employee.
-
Communicate with the team
Once the change is made, make sure you communicate with your team about it. Staff changes are disruptive enough without the ambiguity of not knowing what is going on. A short staff meeting (or an email if your team is remote) to tell everyone what happened and what is going to happen in the future (new responsibilities, change in business goals, a new hire, etc.) will go a long way in helping the team recover and become productive again.
Beyond just the welfare of you and your team, you also need to consider the needs of the terminated employee. Karma works in strange ways and that employee that you sack today, could be a hiring manager in the future. Give every staff member the respect and dignity that you would want to be afforded. Jack and Suzy Welch wrote an article in an earlier edition of BusinessWeek that highlights how to fire someone with dignity and integrity. It’s a good perspective on the inverse of hiring great people.
Whether you are building a new team, augmenting an existing one or filling in some gaps, you want to make sure that you have top notch people. Sometimes that means unloading someone you have hired (or someone you inherited) so that the rest of the team doesn’t suffer. Just make sure you do it the way that you would want it done to you.
Popularity: 48% [?]
Related posts
Tags: communicate, creative solutions, dialogue, dignity, diversity, Documentation, firing, Hiring, HR, human resources, integrity, productivity, underperforming, workplace discriminiation
No Comments »
I wrote a comment the other day on another blog, Security Buddha, in response to a post about how Product Managers (at least not the ones who write blogs) are not really geared for rapid product release cycles. The author had reviewed several Product Management blogs, including this one, and came to this conclusion–
“I can’t help feeling that most of the PM gurus are cut out for old school software development with long release cycles and would balk at the real meaning in the Agile Manifesto.”
My comments on Security Buddha went something like this (paraphrased, but you can see the original here):
“Rapid release cycles can work for some products and I would like to be able to have more frequent releases, but there are trade offs and for me (specifically, my products), the trade offs are too great to adopt a strict Agile or rapid release cycle.”
There are aspects of Agile development (from here on out, I will use Agile to refer to any/all rapid release cycle methodologies; I know that there are significant differences between them, but for simplicity’s sake I am referring to them together) that I believe are beneficial for all software development. I called them out in my reply, but here they are again–
-
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
-
Continuous attention to technical excellence and good design enhances agility.
- Simplicity–the art of maximizing the amount of work not done–is essential.
For some products and software, Agile development works great. Consumer web applications are a prime example. I use several web-based applications on a regular basis (email, RSS, maps, search, auctions, community sites, etc.) and while I don’t expect changes everyday, I like when new features appear regularly and get enhanced shortly after release based on user feedback. I am equally annoyed by new features that don’t work or when features that previously worked get broken or disappear.
In addition to getting users new functionality faster, quick release cycles let Product Managers and Engineering tweak features so that they better match user requirements. Kathy Sierra over at Creating Passionate Users had a great post about a year ago about the impact of Agile development on consumer services like MySpace.
She commented on how her daughter is an avid user of MySpace and one of the main reasons that she (the daughter) loves MySpace is that it is constantly changing and growing organically every day–and that more and more Web 2.0 sites are adopting Agile development so that they can stay competitive. This is fine, but no one is using MySpace or most other consumer web sites as mission-critical software. If they are, they really should look at their definition of mission-critical.
Stability is another reason why Agile development is not always a good fit for software development. For example, enterprise applications are not well suited to Agile development because of the overhead involved in putting enterprise software into production at large organizations. One of my current customers has a 2-3 week validation process (sometimes longer depending on the scope of changes) for any new software before it can be put into production. Another customer has to rely on a third party organization to install any new software into their production environment and it has to be scheduled almost a quarter in advance.
Agile development can also place a significant burden on internal teams. While there is less coding to do during each cycle, other aspects of the release have to be repeated more frequently and at the same level as for longer release cycles. Documentation, Training, QA, and collecting user feedback all take more time in aggregate for multiple small releases than they do for the equivalent larger release. And for organizations that are not practiced in executing Agile, there is a high degree risk involved, too.
Don’t get me wrong, I think Agile can be a useful software development method, but just like religion, there is not one that works for everyone.
NOTE: for an interesting counter-perspective on why Agile is NOT good for any software development, check out this post on Tech Republic.
Popularity: 41% [?]
Related posts
Tags: agile, agile development, competitive, consumer, consumer software, Documentation, enterprise, enterprise software, internal, mission-critical, QA, release cycle, training
4 Comments »
|
Entries (RSS)