Posts Tagged “Customers”
Last week (3Dec09), Forrester Research Analyst Tom Grant led a discussion on Agile in Technology and how it pertains to Product Management. I took some copious notes on the discussion and thought I would share them here.
Be forewarned, some of this may seem a bit cryptic. I was typing in real time (on my new HP Netbook) and participating in the discussion, so I didn’t capture every single piece of the conversation. Plus, they’re notes, so by definition they are brief. I’ll try to add some clarity where I can. Items with ** denote topics that were brought up as part of a response, but not discussed in detail.
<NOTES>
Agile in tech orgs requires company-wide changes to be successful
Topics for discussion (desired @ start)
- Multiple Groups
- Agile Adoption Path
- Communicating Up
- Roadmap
- Associated Groups
- Longer-term Projects
- Cult of Agile
**Does Agile get used for things other than software (service, hardware, etc)?
What does Agile really mean?
- Fail fast
- Rapid iterative sprints (vs. releases)
- Consumer v. enterprise
- Empowering for Dev
- Customers funding development of features (demise of PM?)
- Customers/requirements mob-style
- Discover issues more quickly
**Designating sprints as design or build can provide balance for dev team and product team
What are the characteristics that make Agile truly Agile (are there minimal reqs to be Agile)?
- Daily communication
- User stories
- Coaching (external training)
- Executive sponsorship
**Challenge of balancing defect/feature in sprint/releases
How can Agile better accommodate futures (12 month plan)
- Showing a long-term roadmap that likely won’t happen that way vs. showing a 3 month roadmap that is likely, but without future planning
- Use backlog as “possible” roadmap
Challenges of Waterfall and Agile turn out to be very similar, but are labeled differently
1st age of Agile is done, moving to 2nd age where Agile is more broadly adopted and enhanced
</NOTES>
Popularity: 2% [?]
Related posts
Tags: agile, backlog, balance, challenges, Customers, Design, forrester, product management, requirement, roadmap, sprint, tom grant, waterfall
No Comments »
And these days, who isn’t?
My company is having a webinar this month covering how to put together a Social Media strategy for your company or organization. If you (or your company) haven’t figured out to monitor and utilize social media channels, then this is a good primer.
It will be heavily geared toward marketing folks (hey, that’s who our customers are!), but even if you don’t fall into that category, there’s good info that may be useful for you as you find new ways to collect data about your products and services and interact with customers and prospects in new ways.
Here are the details:
How to Implement a Social Media Marketing Strategy
Presented by Marcus Tewksbury, Director of Alterian Customer Intelligence
Thursday, December 17th 10:00am Central / 16.00 UK
To register: http://www.alterian.com/smleadgen (Tell ‘em The Productologist sent you!)
What you already know: Your emails are starting to fall on deaf ears; the quality and ROI of your PPC campaigns are on the decline; and your prospects and customers are spending more and more time online, but not necessarily on your site.
What you need to know: Social media can address all of these issues in a measurable, programmable way by taking the brand experience to the community and engaging people where they form impressions and find answers.
In this webinar, Marcus will walk through the steps that can make you a social star. He will cover:
- Tracking customers online and identifying the right social channels
- Creating content that sticks and sells
- Crafting calls-to-action that are tailored to the social media
- Being accountable, and showing straightforward ways to demonstrate lift and ROI
- Developing a search strategy that gives your content the best chance of being found
- Enabling new social channels like LinkedIn, YouTube, and Twitter to cheaply and efficiently spread your brand message
- And much more…
Popularity: 2% [?]
Related posts
Tags: brand experience, community, customer intelligence, Customers, Marketing, media strategy, products, Prospects, strategy, twitter, youtube
No Comments »
In the interest of good karma, here are two Product Management job posting that I have heard about. These are REAL PM jobs in the SF Bay area. If you are interested, let me know and I can get you in touch with the hiring manager (no recruiters, please)–
- Product Manager @ Loomia [POSITION FILLED]
ReadWriteWeb recently said: “Take a look at what Loomia is focusing on in 2009, which is an indicator of what media websites must do to ramp up this year”
Our innovative technologies have caught a few eyes because we’re leading the way in content recommendations. Our customers include: Time, Forbes, WSJ, PC World, US News, Harvard Business Publishing and many more!
Are you passionate about building a great product our customers will love?
We are looking for a Product Manager who is excited about the opportunity to further Loomia’s leadership in the marketplace, and will take pride in ensuring customer satisfaction with our suite of offerings.
More info can be found here:
https://www.jobscore.com/jobs/loomia/productmanager/cYNhW8JeOr3R5meJe4aGWH
- SaaS Technical Product Manager, DDM @ Dell
As Technical Product Manager, you will serve as the voice of the customer and product management for our engineering and quality teams. This extends from identifying and prioritizing sustaining improvements that address the profitability and quality of existing products to developing new products for the company. You will contribute to requirements from existing ideas, and help to develop new ideas based on your industry experience and your contact with customers and prospects. You will work directly with the engineering team building the product, and communicate product requirements and technical specifications and provide strong leadership at a product technical level. You will become a market and product expert, and understand the pain of different personas both inside and outside the company.
You must possess a unique blend of business and technical savvy; a big-picture vision, and the drive to make that vision a reality. You must enjoy spending time in the market to understand their problems, and find innovative solutions for the broader market.
Popularity: 3% [?]
Related posts
Tags: Customers, industry experience, jobs, Loomia, Personas, product expert, ReadWriteWeb, SaaS, Technical, voice of the customer
No Comments »
 Image by mino_andrade via Flickr
Alright, people, Summer is over (again, just for you Northern Hemisphere dwellers)! Time to kick it back into gear. I hope you all kept up with your Summer reading list. You’ll be expected to discuss the following (with cited examples):
-
Thoughts: Duplicating the “Apple Effect”
[AckNak]
-
Does a product manager have a natural life-cycle?
[Carl Knibbs]
-
Tr.im should have figured out their revenue model first!
[On Product Management]
-
Your Best Customers Probably Aren’t
[Experience is the Product]
-
Agile Testing versus Waterfall Test Phases
[All About Agile]
-
Your product launch wont be successful if your sales team doesnt trust you
[Launch Clinic]
-
Mock-ups Made Easy!!
[Product Ninja]
-
A Simple (?) Question …
[Outside InView]
-
10 Ways to Identify an Impending Product Launch Disaster
[Launch Clinic]
-
Developing a Product Idea Presentation
[Grace Hu-Morley]
-
What is a product specification?
[Effectivus]
Disclaimer: Just because I include a link to a particular posting, that is not an indication that I agree with the original author. In fact, I may post topics that are the opposite of my views or at least somewhat controversial in order to provide a contrasting viewpoint to the one I present on The Productologist.
Popularity: 3% [?]
Related posts
Tags: agile, customer, Customers, mock ups, product launch, revenue model, waterfall
No Comments »
Last time on the Product Management Question Corner, I announced that there was only one more left to post. That was true, until Jason Miceli, self-described Product Ninja, answered my tweet requesting more volunteers. Jason is VP of Product Management at Perimeter eSecurity, a provider of on-demand information security services for enterprises of all sizes. Jason has a long history of working in IT software and leading IT projects. In this session, Jason provides some keen insights on being a Product Manager in the trenches, as well as what’s the haps for Product Management leadership.
Q: How did you come into the role of Product Manager and was it planned?
A: Well that depends on what you mean by “planned”! If you asked me 5 years ago if I planned to be in a Product Management role, my answer would likely have been, “Are you kidding me?” However, the evolution that brought me to this ultimate role certainly felt natural – so you might say it was “sub-consciously” planned!
When I began working for my current employer I was hired as the Director of Special Projects, which quickly turned into the VP of Project Management after they saw the success of throwing a “special ops guy” at the crazy one-off projects that no one else either wanted or understood. Once that role also proved to be successful the company made another course correction, stating they wanted me to focus my efforts toward the projects that produced revenue, thus my final transition to VP of Product Management.
Now at first I attacked this role primarily from a project management perspective, given my background to date, but then quickly began to fall in love with and embody the full sense of Product Management. Now I truly could not see myself doing anything else!
Q: What was your worst Product Management mistake and how did you recover?
A: I’d say my worst Product Management mistake was probably being “too much” of a team player on one particular project. At the time of this project we had a very clear line of delineation between the Software Development phase and the Product Launch phase. This project had been in design and development for almost a full year, and so everyone in the company was nearing their limits with how much longer they would tolerate project delays – the notion of scrapping it had come up more than once. Knowing this, and trying my best to convince executive management it would be a mistake to scrap the project where it stood, I prematurely “accepted” the project into the launch queue. I said I would do my best to fast track the User Acceptance Testing (UAT) and public beta steps, hoping that would help everyone to see the light at the end of the tunnel… unfortunately the product was still VERY deep in the tunnel, and so because I did not mutually accept the project’s discontinuance when I had the chance the result was a bit more egg on my face when that same inevitable outcome occurred.
Why did I take this approach? Because I knew how much would have been lost by scrapping the project where it stood – efforts by my team and countless others to design the product’s functions, features, benefits, GUI design, database and systems architecture, prototype environment, hundreds of software development man-hours, etc. – it killed me to think about all that effort being lost and so I looked for any way I could to keep the project alive and not see it all go to waste. In the end, no matter what happened it was destined to become a failed project, a reality every Product Manager must eventually face, but I made the situation far worse and essentially wasted more time and resources in the process. A great learning experience to be sure!
Of course this case study would also be a great to show how an Agile methodology could have prevented this entire disaster from ever occurring in the first place!
Q: How do you see the role of the Product Manager changing in the next 5-10 years?
A: I believe the concepts of Agile are really starting to take off, and we’ll see a tremendous move towards that methodology over the next 5 years. Accordingly, the notions of Product Manager, Product Marketing, Product Owner, and a couple other key roles will really start to take shape and become more widely known and understood throughout the industry. This is a fantastic evolution, and one I will fully embrace and foster in any way I can!
Q: If you could be the Product Manager for any product, what would it be and what would be the first thing you would do?
A: Of the known, current products on the market I would gladly take product ownership of eBay. eBay’s success is undeniable, but I believe there are key ways the core product can be enhanced to cater to a wider audience. Most notably I believe the product’s accessibility is lacking. Based on research I’ve performed recently there are many who choose not to post items on eBay due to the perceived complexity in doing so. While I don’t consider the overall posting process to be “complex” I do believe there are ways it can be modified to offer a far simpler and more streamlined approach that would entice the average user to make better and more frequent use of the system.
Q: What Product Management tool could you not live without and why?
A: At the moment I’d have to say Microsoft SharePoint. I have been building out some fairly detailed custom tables that interrelate in ways allowing for fairly decent tracking and visibility of many Product Lifecycle Management (PLM) concepts. Of course there are commercially available tools that do a far better job given their direct focus on PLM, but absent of the necessary budget dollars to purchase such a product I have found it surprisingly effective to recreate much of this functionality in SharePoint. We started with a simple projects list and have since expanded to include our formal product catalog, user stories repository, supported platform matrices, regulatory language and mapping database, and several other tables, each of which link to associated master tables creating a very dynamic work environment. Most importantly, creating structures like these within SharePoint has proved to be extremely simple – I was able to accomplish all of this myself, without seeking any assistance from engineers or development resources.
Q: What is your greatest Product Management achievement?
A: Building a thriving Product Management department from ground up – I truly could not be more proud of the tremendous success our team has been recognized for repeatedly! One of my proudest moments was shortly after our new Chief Strategy Officer came on board and quickly admitted he had never seen Product Management working so well in any organization before. In his words, “he has Product Management singing!” To further that notion, I was equally proud the day I turned over management of all product launch responsibilities to a gentleman I had hired less than a year prior – to me there’s no greater measure of success for a manager than to build up a process to such a point of efficiency that it no longer requires his or her direct involvement!
Q: What have you done or what would you consider the best way(s) for Product Managers to improve themselves?
A: In every sense of the phrase, “Get out there!!” Get out to the market and understand it. Get out to your customers and listen to them. Get out to conferences with your peers and learn from them. Get out to the industry and become a leader. Just get out there!!
What you should be building can come only after you’ve accomplished this – then you can be sure you’re building the right thing, the right way.
_____________
And now for Jason’s question for The Productologist:
Q: What would you consider the *best* possible organizational structure as it relates to Product Management, Product Marketing, Development, Corporate Marketing, and any other key department(s) you feel are part of this picture, starting from the CEO and working down?
A: The organizational structure of a company depends greatly on the size and maturity of the organization and the orientation of the leadership team. At most software startups, the Engineering team gets built first and then there is a realization that the founder(s) or Dev team are not in a position to actively manage the product, so they look to hire a PM to take over the reigns.
At more established companies, a new product is assigned to an existing PM, who likely has 3 or more products/services that they are already responsible for managing. If they are lucky, they are pulled off of the other products (or at least reduce their day-to-day responsibilities) to focus on the new product.
In either case, the PM has an uphill battle for time, attention, resources, and money.
In startups, PM usually falls under Engineering. In older organizations, they tend to fall under the broader Marketing umbrella or be a stand-alone team. Each structure has it’s strengths and challenges, which have been and continue to be debated in the PM community, but the one I think functions best for the role of Product Management is being a stand-alone team.
While this usually means giving up the stature, influence, and budget of being part of the Marketing or Engineering teams, the autonomy and ability to operate between these two powerful entities best suits Product Management’s true charter–to listen to and observe the market and provide guidance on how to maximize the value of that information into an executable product strategy.
Product Managers wear many functional hats and go by many monikers, but ultimately, their primary responsibility is to guide their product(s) to success, whatever shape that might take for their product or company. Success could be revenue or users or media attention or downloads (best to set that metric at the outset in order to make sure you are prioritizing correctly), but whatever it is, the Product Manager is the one whose head is on the platter if it doesn’t happen.
If Product Management sits within either Marketing or Engineering, I believe that they are too constrained by those teams’ other mandates to effectively perform their own duties. Don’t construe this to mean that I see PM teams that are structured within those teams to be doomed to failure. I have, in fact worked on teams in both of those scenarios, with much success. But at the time, my PM goals, as designed by the executive team, were aligned with one or the other of Marketing or Engineering, which is why those arrangements worked. I don’t see that as being ideal for the true function of Product Management.
Having a stand-alone Product Management team means that you have to have STRONG Product Management team. Ideally, it means have a VP of Product Management who is on the same level as Marketing and Engineering, reporting directly to the CEO (or COO or whomever Marketing and Engineering report to). That gives Product Management a voice at the executive table and enough influence to drive not just the product roadmap, but the product strategy.
If there isn’t a VP of Product Management, then you really have to have STRONG Product Managers. And by strong, I mean being able to go into the CEO’s office and say things like, “No” or “I need X to make this product successful” or “We can do that, but that will affect all of our current product plans for the next X months. Here’s why I wouldn’t recommend that.” With data to back you up, of course, but you have to be able to say those words. Otherwise, Product Management will always be a second-class citizen to some other organization that can say those things.
So in an ideal world, here is what the corporate structure looks like (I have not gone into detail about what happens within other teams, just the product team):
A word about UI design sitting within the Product team. I think this is a crucial element of the Product team that is missing 99% of the time. Design is an important market requirement, and too often it is relegated to the function of making already-built functions “prettier.” Design in software is more than look-and-feel. It is the workflow and ease-of-use and extensibility of the user experience. Design is fundamental in the success of software. Apple is the quintessential example of this. I am no Apple fanboy, but I recognize the obvious fact that their products START with design, rather than end with it.
A bit more about Jason:
Jason has held key leadership positions within his organization for the past five years. He is directly responsible for a portfolio of 30+ services totaling over $30 million in revenue and has helped to define the rapidly emerging Software as a Service (SaaS) market within the security and technology space. Often referred to as the “most detail-oriented person who can remain optimistic,” Jason is further unique in his love for the “art” of creation. In addition to product management, Jason has served as the lead for key mergers & acquisitions, new remote offices, and department startups, responsible for smooth integration of new products, staff, and business processes. Jason is published in several security magazines, including CSO, and was recently a speaker at ISPCON.
Popularity: 5% [?]
Related posts
Tags: agile, agile development, business problem, challenges, customer experience, Customers, diagrams, enterprise software, feature set, Interviews, large corporations, Management, measure success, priorities, product management, product roadmaps, product team, product vision, release cycles, software development life cycle, start ups, stategy, Usability, user experience, users experience
5 Comments »
Today’s edition of the Product Management Reader is powered by gin and tonic, so pay extra close attention for bonus wittiness and idle banter. And would you believe two separate posts from two separate Product Management bloggers about blenders? BLENDERS! It boggles the mind. Plus, there may be an exhibition by that ever-elusive double entendre. Eyes wide open, now.
-
Agile Maturity Model – What’s Next?
[Tyner Blain]
-
Advice for up and coming Product Managers
[All About Product Management]
-
The Quarterly Vacation
[Product Management Zen]
-
How the Blender illustrates “designing the product” vs. “designing the whole product experience”
[Experience is the Product]
-
The value of simplicity
[On Product Management]
-
I blame the the Product Manager
[Cranky Product Manager]
-
VC Pitch Template
[Rocket Watcher]
-
Lessons from a Bad Haircut
[Requirements Defined]
-
Visiting customers “in the wild”
[ProductMarketing.com]
Disclaimer: Just because I include a link to a particular posting, that is not an indication that I agree with the original author. In fact, I may post topics that are the opposite of my views or at least somewhat controversial in order to provide a contrasting viewpoint to the one I present on The Productologist.
Popularity: 3% [?]
Related posts
Tags: agile, Customers, Design, maturity model, product experience, product management, Requirements
No Comments »
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 »
Tired of hearing the U.S.-centric view of the world? Me, too. So today, we’re talking to Donal Kane, a Product Manager from the United Kingdom, who works at Mediaplex, the technology division of ValueClick, an online marketing company focused on ad serving, customer acquisition, and affiliate, email, and search marketing. Donal takes us on a journey that starts in Medieval times and ends up 24 months in the future.
Q: How did you get involved in Product Management?
A: I guess I’ve a somewhat unconventional academic background for Product Management having studied Medieval History and Economics in University. I’m sure there’s a good joke somewhere about studying the religious warfare in the Middle Ages and the position of product management in an organisation but I haven’t come up with it yet! Seriously though I would say that an analytical mindset and the ability to clearly communicate requirements and requests are something that’s more important to successful product management than anything else.
Following university I wandered into Software Engineering and then equally accidentally ended up in online advertising at Doubleclick’s European HQ in Dublin back in late 1999. I started out in Technical Support and after moving up through the ranks with Doubleclick for over 5 years I moved across to ValueClick in 2005 as European Product Manager, initially in the Mediaplex business and more recently in Commission Junction as well.
Q: Where is the best place for the Product Management function in an organization and why?
A: My product management experience has been focused on working in remote offices at quite a long distance from the engineering teams and the core product managers; this probably gives me a slightly different perspective on this than some of your interviewees so I would give a geographical answer here and say the best place for the Product Management function to be located is in the same location as the main engineering/development, in my experience anything else doesn’t really work.
However I think there can be a danger of Product Management being “captured” by the engineering function so some organisational distance is useful in maintaining a degree of independence and avoiding Product Management becoming too close to Engineering/Development. It may be useful for Product Management to sit with Engineering, but if they have lunch with them every day too that’s probably too much!
Q: If someone told you that they wanted to be a Product Manager, what would you tell them?
A: I think it’s far more important to be interested in the product than to want to manage it. If you’re interested in the product and you understand well what it does and how it’s used then that’s the most important part of being a Product Manager. I’d always encourage people to work in a business they’re interested in rather than concentrate on a job title in a business they may be less interested in or have less aptitude for.
Q: What have you done or what would you consider the best way(s) for Product Managers to improve themselves?
A: Always be conscious that your users and customers (internal or external) probably aren’t using your product in the way you intended them to use it, or the way you think they want to use it. It’s always a useful exercise to “walk a mile in someone else’s shoes”; spend some time on client calls, support tickets or RFPs to get an understanding of what’s really going on out there with your product.
I think it’s critically important to avoid the “ivory tower” mentality with Product Management, just because you think you know the best way to do something with your product doesn’t mean that that you’re correct and even if you are it doesn’t mean it’s immediately obvious to everyone else.
If you talk to your customers and users you’d often be very surprised at how their usage of your product diverges from the ideal that you have.. sometimes (in fact quite often) your users may have come up with a better way to use your product than you would have thought of yourself.
Unless you understand in detail what your users are doing with your product, and why they’re using it in that way you can’t be an effective Product Manager.
Q: What was your worst Product Management mistake and how did you recover?
A: Spreading myself too thinly across the business so I can’t properly practice what I preach with everything I work on and really learn in detail how a product is interacted with by the users and customers.
Recovery is a slow process and I don’t think I’m there yet!
Q: If you could be the Product Manager for any product, what would it be and what would be the first thing you would do?
A: Microsoft Windows, and the first thing I’d do is roll back to XP and keep the only genuinely good feature on Vista – the “Snipping Tool.”
_________________
And now for Donal’s question for The Productologist:
Q: When it comes to roadmaps and strategic product planning what’s the optimum level of forward planning you should do ? … It always seems to me that while a little planning is undoubtedly a good thing, too much planning is bad as you lose flexibility and can become hostage to your own plans. Finding that balance must be hard .. any tips?
A: Plan for change. The problem that a lot of Product Managers get into is that once they put something into a product plan (or roadmap or whatever you want to call it), it’s set in stone. Sales saw you present it at the last quarterly meeting. The CEO mentioned it at the board meeting a week ago. That customer you showed it to wants to know when the feature that is 3 quarters away will be done.
In general, I like to think of the roadmap more like a compass. It helps you understand and communicate the general direction you want to go. If you commit to it like an unbreakable contract, you may end up doing something that is out of line with your business by the time you get it done.
For folks who are trying to figure out a roadmap, I usually give this advice:
6 month roadmap should be cast in clay. It’s pretty stable, but it’s not cheap. It takes a lot of work to build it. You can be modify it slightly if necessary, but it’s gonna cost you.
12 month roadmap should be cast in marshamallow creme. It’s big, fluffy, and tasty. You can shape it any which way you like and if it doesn’t look right, you can throw another dollop here and there to easily adjust it. Plus it doesn’t look real, so no one will expect you to actually deliver it.
24 month roadmap should be cast in pixels. Nothing there, but pictures that can easily be modified to suit whatever business whim you need. It’s low-cost (except the labor), infinitely tweakable, and can be as big and fantastic as you can dream up.
A lot matters about your company and product(s), too. Big companies usually require lots more formal planning. Young, small companies are flying by the seat of their pants and planning more than 3 months out might seem ridiculous.
As the Product Manager, you have to drive the planning process. Figure out what works best for you, your team, your company, and your product(s). But don’t get stuck just because you think you found the right cadence and detail. Hopefully, you company is growing and changing, so you’ll need to keep evaluating whether your product planning process is still effective.
A bit more about Donal:
Donal has been working in Online Advertising in Europe for almost 10 years and is currently Director of Product Management for Mediaplex in Europe, working out of the ValueClick offices in London.
Popularity: 13% [?]
Related posts
Tags: balance, customer, Customers, Engineering, experience, mistake, product, product management, product planning, roadmap, Success
4 Comments »
A funny thing happens at my house. BW and I have very different tastes in magazines. In my pile are issues of “Snowboarding”, “Harvard Business Review”, “Fast Company”, “Inc.”, and ” The Economist”. BW’s pile consists of much less business-oriented fare that includes, “Organic Gardening”, “Martha Stewart Living”, “Cooking Light”, “The Sun”, and “Vanity Fair” (I look at that one, too, but only for the articles <smirk/>). Inevitably, we end up reading something from each other’s pile, either because we see an article of interest, or there simply isn’t anything else to read.
Recently, BW has started getting another periodical. It’s called “Brain, Child“. It’s comprised primarily of essays from professional writers and reader-generated content around mothering issues. Some of the topics deal with non-gender-related parenting issues, but by-and-large, it’s for the ladies. It’s not the kind of magazine that I would subscribe to normally, but BW picked it up from a friend and really liked it, so I bought her a subscription for her birthday. I read the first issue that arrived and didn’t really care for it, but BW loves it.
In one of those situations where there wasn’t anything else to read, I picked up a recent copy and started thumbing through it to find one of the less painful-to-read articles. I stumbled upon an article about non-custodial parents and the issues that they run into when dealing with what most parents would consider mundane. Things like requesting your child’s medical records or being notified about issues at school.
The author of the article was a woman, who as it turns out, is the non-custodial parent of her children, a situation that is uncommon, but not unheard of (part of the article explains the backstory about this). She elaborates on the double-edged sword that comes along with being a woman and the non-custodial parent and how she is treated by MANY people even though she is LEGALLY entitled to perform the actions and request the information about her children that she does.
What I found interesting about the article (and admittedly, this is a pattern in the type of content in the magazine as a whole) is that what she describes is an EDGE CASE. As Product Managers, we run into these all of the time when dealing with feature requests, reported defects, prioritization, and overall product strategy planning.
Edge case is a fighting word. Everyone, including Product Managers, engineers, QA, training and documentation, and support use “edge case” to describe something they don’t want to address. It’s a dismissal. It means that the issue exists, but it’s not significant enough to do anything about it.
The problem with edge cases is that they ARE real, especially to the people experiencing the edge case issue. But we sweep them under the rug because the majority of users don’t experience the issue. I’m as guilty as the next Product Manager of using the “edge case” battle cry for trying to keep releases on schedule or keep developers focused on the core function of the software, but it’s important not to just dismiss edge cases out of hand and never revisit them.
Edge cases sometimes make good fodder for niche products. If one user is experiencing the problem (and sharing it), there are probably others, who are keeping it to themselves. You’ve heard the saying about cockroaches.
You can also use edge cases as a litmus test for what will grow into a more profound issue for your mainstream users. Think about that edge case user as the leading edge rather than the side edge. Evaluate whether you are likely to see more of the edge case rather than less. Being premptive about addressing it before it affects the main pool of your users could save you and your support team from many painful calls with unhappy customers.
Like the challenges of the non-custodial parent we started with, there are many small, but very real issues out there. Just because you don’t see it very often doesn’t mean that it doesn’t matter. We Product Managers have to open our eyes wide and look around. Next time, look for what might not be so obvious.
And the next time you start to say, “That’s an edge case, because….” stop and ask yourself if it really is.
Popularity: 15% [?]
Related posts
Tags: challenges, cooking light, Customers, economist, harvard business review, martha stewart living, medical records, non custodial parents, organic gardening, products, software, training, vanity fair
1 Comment »
|
Entries (RSS)