Posts Tagged “Engineering”
Well folks, this is it. The FINAL PMQC. Today we are talking with Amita Paul, Founder of ObjectiveMarketer, a solution for extending Marketing, Sales and Customer Service into Social Media. This session has been in the works for a looong time. Originally, Amita was going to write some guest posts for The Productologist, but we couldn’t quite get the timing right. Then she started working on ObjectiveMarketer and as anyone who has started their own company knows, there is not much time for extracurricular activity. Ideally, this interview would have fit in with the entrepreneurial ones I did a while back, but alas, it was not meant to be. Anyway, this one promises to be a good one.
Q: How did you come into the role of Product Manager and was it planned?
A: At the risk of sounding cliché, let me tell the story that has been my inspiration all this while. It goes like this – “At a construction site, one could see three workers doing the hard work. When asked about the work, one said, he was laying bricks for the foundation, the other said, he was carving stones, but the third one said, he was building a temple.” I had heard this story at a pretty young age, when I was still in my school and had zilch experience. But, I instantly could relate myself to the story and specifically, the third construction worker.
Fast forward a few years (1999), and I am in my first job as s/w engineer (in India) for a big multinational, where for first few months, all I did was fix typos and alignments in some random reports. Soon, I realized, pretty much every engineer in the company did the same! Frustrated, I cursed myself. Leave aside the temple; I could not even see the bricks!
Fast forward 10 more years (2009). Day in and day out, I am doing nothing but thinking of the temple that I am trying to build. Sometimes, I have the bricks and mortar. But, mostly I have nothing more than a huge space! How did this happen?
So, to answer the question – the role of Product Manager was not planned, but was envisioned! I continued doing things that I loved – defining product features, integrating technologies, creating collateral – even when I had the designation of Software Engineer, much to the chagrin of my manager. However, after I did my MBA, I moved into the formal role of Product Management.
Q: What are the biggest challenges you have experienced as a Product Manager and how did you overcome them?
A: PACE and RISK PROFILE – the two differences between you (the PM) and your people!
As a PM you are churning ideas, snooping every possible place to combat competition; and geared with that momentum you draw the most powerful roadmap. The biggest challenge then is to convince the engineers “Man, this needs to get out the door like yesterday!” and to tell the management “No, this is not as risky as it looks. And yes, let us take this risk! May be this time! Please?”
These are hard nuts to crack though! And sometimes, I feel “wish, I still did code”.
Q: What have you done or what would you consider the best way(s) for Product Managers to improve themselves?
A: Considering that fundamentals of Product Management are clear (there are myriad of good advice on the net including “The Productologist”), these are some of my tips -
- Be visible, be available and be ready to speak up. It is your product and you have to protect it and promote it all the time – in meetings, in cafeteria, in restroom, in elevator, in carpool…
- Become multi-lingual as fast as you can. With engineers, with sales folks, with management, with customers, you should know to speak their lingo. Listening to what these different groups mean and presenting your concepts to them in a way that they can understand, is the key.
- Be quick in rectifying mistakes. Do not get obsessed to an idea to the extent that it becomes overkill. Accept, learn and move forward. If there are human beings in your organization, they will understand.
- Take break. No work for sometime is not a bad thing. Free up your mind from overworked issues, solutions and situations. Start afresh!
- Finally, never forget the temple that you are trying to build. Even, if it is an iterative project, there is always a temple within a temple!
Q: Where is the best place for the Product Management function in an organization and why?
A: I believe Product Management should be tied with P&L responsibility. So, in an ideal world I would like to see Product Management being managed as an independent function –tightly integrated with Marketing, Sales, Engineering and Finance – but, not under any of them. Being outside of a group has its own disadvantages – most importantly loosing the influence in decision making. That rests on the capability of the people who run this function.
Q: If someone told you that they wanted to be a Product Manager, what would you tell them?
A: Go ahead! But, wait a minute … do you see the temple???
___________
And now for Amita’s question for The Productologist:
Q: In last one 5 years if you were to pick one, which technology product or service would you call par excellent and why?
A: Even though it’s not so much a technology in and of itself, but rather a use of technology, I feel that the advent of tools for creating User-Generated Content (UGC) has had the most profound impact in the past 5 years. When the Internet was first made commercially available and followed shortly thereafter by the Web, it was primarily corporate entities that claimed the space to broadcast their ideas. Websites popped up here and there and even though almost anyone COULD create a website, almost nobody knew HOW to create websites.
Then along came tools and apps that allowed less technical folks to create content on the Web. Sites like Tripod and GeoCities let laypeople create content without having to know much about the underlying HTML code. Granted, most of it was atrocious looking (who can forget the <blink> and <marquee> tags of early HTML pages?), but it was the first steps of the public having direct access to a large-scale publishing and broadcasting medium.
Over time, more powerful tools emerged which allowed non-technical users to embrace more of the computing side of the web. Apps like Dreamweaver let designers build websites that were connected to rudimentary databases (often just excel spreadsheets) to generate pages on the fly.
Some years later, blogs started to emerge and once that happened, it was as if the floodgates had been cast open. The number of pages on the Web grew astronomically. The same problem of signal-to-noise remained, but new voices were heard and new viewpoints were put forth and discussed.
Social Media is an interesting extension to that. I am not sure where it will go, since it is such a broad category and it includes many diverse areas, but to be sure, sites like Twitter, Facebook, LinkedIn, and others have made a significant impact on the role of communication in the 21st century.
A bit more about Amita:
As a founder and CEO of a new startup, ObjectiveMarketer, Amita is fulfilling the most challenging Product Management function of her career so far. ObjeciveMarketer is a comprehensive marketing platform for social media, offering campaign management and analytics solution for Twitter, Facebook, YouTube etc. She is focused on growing the business and building functionality that will increase adoption of social media as a viable business channel. All in all, it is fun and I am enjoying every moment of it. To connect with her, you can follow @amitapaul or @objMarketer on Twitter or through LinkedIn and Facebook.
Popularity: 3% [?]
Related posts
Tags: Design, Engineering, Marketing, roadmap, Startup
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 »
The Product Management Question Corner has been on a bit of a hiatus, but we’re back with a vengeance. Today, we are talking with Jamal Ahmad, Product Manager at FrontRange Solutions, a CRM and IT service management provider. You may be familiar with their helpdesk app, HEAT or their CRM application. Jamal came to Product Management from Engineering via a host of other roles, but he’s never looked back.
Q: How do you see the role of the Product Manager changing in the next 5-10 years?
A: Let’s start with the impact of major trends. A couple trends that we hear about every day are the recession and growth in social media. Here’s my take on how they will affect product management over the next few years.
“Do more with less” is a common theme these days, and Product Managers are not exempt. I think you will see flatter product management organizations and fewer supporting resources available to product managers. Like it or not, we product managers have to fill gaps, and the gaps are going to get wider. This means fewer specialists and more demand for product managers with a flexible skill set. We have to work with executives and define strategy but also manage the tactical details. In many organizations it has always been this way, but now the big companies are cutting back. I think that individual product managers will end up with a wider scope of responsibilities.
The other trend is social media – online communities and forums in particular. Sure, they’ve been around forever but user adoption still is increasing. As online communities become more mainstream, their value as feedback mechanisms goes way up because they no longer represent just the enthusiastic fringe. Communities give opportunities to engage with customers and hear what they have to say. What problems do they encounter in running their business? What questions are they asking about your product?
Q: If someone told you that they wanted to be a Product Manager, what would you tell them?
A: I think it’s a great idea. Being a Product Manager will leverage all your abilities and expose you to many elements of running a business. If you want my advice, find an organization where you can focus on the market, not dealing with internal bureaucracy or watching your own back. Talk with as many people as you can when you’re interviewing and see how they like their company and their role. Product Management isn’t for everybody, but for the right person in the right situation, it can be a dream job.
Q: What have you done or what would you consider the best way(s) for Product Managers to improve themselves?
A: Keep yourself challenged. Get out of your comfort zone. If you feel most comfortable when dealing with technology, take on some marketing responsibilities to broaden your skill set. If you’re the “big picture” type, dive into the details for a change.
In my own experience, getting an MBA was a great boost for my career. It let me transition from an engineering role into a marketing role, and I would have had little opportunity to do that otherwise. If you’re already in a Product Management position it’s harder to justify the cost of going back to school, and you’ll have to look for other ways to develop new skills.
Q: What Product Management tool could you not live without and why?
A: Microsoft Word (actually, any word processor would do, but that’s the one I use). Pretty basic stuff, but the main thing is that you need a formal way to communicate market feedback and requirements. A release tracking system is a valuable tool, but if you just track issues and features as line items, it’s hard for anyone to see the big picture.
Competitive positioning targets, market feedback, competitive analysis, strategic objectives, etc. are important to communicate to engineers. When it comes time to explain why Issue X really matters for this product release, you can tie it back to the business objectives. When you see emails flying around about irrelevant Issue Y, you can gently remind the engineers (and yourself) to focus on the things that were defined as priorities from the beginning. It’s all there in the document.
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: That’s an easy one… Guitar Hero. First I’d lose the lame hair metal bands of the eighties, because who really wants to pretend they’re Warrant? (I hope Warrant doesn’t read this blog.) Add some tracks from bands with intensely loyal fans – that might bring in some new customers.
You didn’t ask, but the second thing I’d do is get the engineers to come up with a way to put more buttons on the guitar, for a little more challenge and realism. I know there are some technical limitations that make this difficult, but I’ve got to believe there is a way to make it happen. Otherwise the game’s going to get old.
_________
And now for Jamal’s question for The Productologist:
Q: I brought up a couple of trends that everyone already knows about. What trend do you see that’s outside the clear field of view, and how can I use this information to make my company’s earnings double every quarter for the next 5-10 years?
A: Oy! Raise your hand if you want a magic pill that solves all the worlds ills. Ooh, me, me, me. Unless your company’s current earnings are about $1.00 this quarter (and for some of you out there, that may be true), doubling them every quarter for 5-10 years is a very tall order.
Just to put it into perspective, if you started with $1.00 in earnings your first quarter and you doubled it every quarter thereafter, in 5 years, you would have $524,288.00 in earnings. By the time you get to to 10 years, you’d have more than 1/2 TRILLION dollars in earnings. Not impossible, but certainly not the kind of returns that you should rely on for your next product roll out.
Now, about that trend.
In my view, location and situation awareness in applications is going to start becoming more ubiquitous. Right now, GPS is becoming much more prevalent in our everyday lives, from built-in GPS in vehicles to portable GPS units, even in cell phones. But GPS tools still rely on humans to tell the software what we want to do with the location information.
If I am in my car and driving to a destination, the GPS can tell me where I am and what route I should take to get there, but I have to tell it that I am hungry and want to find a nearby restaurant or that I am tired and would like to find a hotel for the night.
In a travel scenario, I see some AI or fuzzy logic making recommendations about the route based on where I am, what time of day it is, what day of the week, my speed and other locations that I have been recently. For instance, if the software knows that I am traveling a long distance and that it’s been 5 hours since I last stopped, it might recommend a restaurant coming up on my route (especially if I am approaching a cluster of restaurants and that food will not be available for some distance afterwards). It might also make a recommendation based on other restaurants that I have gone to or searched for recently.
GPS might not be the system that provides all of the location or situation awareness for every application, but more and more, software will need to evaluate the situation it is being used for or for the user, based on a variety of parameters. It will then adjust or make recommendations to the user that are relevant.
The user will still have options. Nobody want to end up with a solution like HAL (queue 2001 theme music) where humans are removed from the decision process entirely, but software applications will need to become more than just tools for helping humans accomplish tasks. They will actually HELP humans accomplish tasks.
What to do with this information
I don’t see making this radical jump overnight. Don’t expect something like the ship computer from Star Trek (I know, another science fiction reference…color me geeky). But Product Managers, designers, and developers should start thinking about ways that their products can use information that it already has to improve the user experience.
Think of the Microsoft Office Assistant applet (I know, it hurts me, too). This was actually an interesting example of what I am talking about, albeit, horribly implemented. If the software thought you were trying to create a certain type of document, it would ask you if that was the case and if you needed any assistance. The problem arose in the fact that it tried to help before you really needed help, which turned out to be annoying to most users.
For software to overcome the annoyance factor, it has to be able to recognize that not all patterns are equivalent. If I open a new document and type “Daar Steve,” and nothing else and then 5 minutes elapses, am I stumped on how to write a letter or did I get distracted by some other task?
If the software could be aware that you have a meeting scheduled on your calendar or that your phone is in use or that you have written MANY other documents that follow the letter format, it’s probably safe not to ask if you need help writing the letter.
Software is meant to be helpful, but it only succeeds when it doesn’t annoy us so much that we stop using it.
A bit more about Jamal:
Jamal started his career in engineering, with two degrees and four years working in that field. He decided to pursue a role with an emphasis on marketing, so he moved to California for the MBA program at UC Berkeley. After stints in product marketing, venture capital, and strategic marketing, Jamal made the move to Product Management. He has worked for several companies including Symantec and Akamai, and is currently responsible for the GoldMine CRM product line at FrontRange Solutions.
Popularity: 14% [?]
Related posts
Tags: big picture, CRM, Customers, Engineering, feedback, focus, issues, Marketing, MBA, priorities, process, product management, product release, requirement, strategy, travel, user experience
2 Comments »
Today, we are hearing from Luis Rojas, Director of Product Management at StrongMail Systems. Luis is a Product Manager who has his feet firmly planted in the realm of Technical Product Management, which is a slight departure from the more Marketing-focused Product Managers that we have spoken with in the past on the Product Management Question Corner.
Q: What was your worst Product Management mistake and how did you recover?
A: Early on, I assumed that a sales channel that had been successful in selling one type of product would be successful selling a higher end solution to the same customer base. The company that I worked for was selling a very successful mid-tier product line through an indirect sales channel. This allowed us to put a lot of feet on the street while keeping the overall cost of sales down. The company was obscenely profitable and was selling circles around the competition. Then we had our IPO and started on an acquisition “binge.” We started buying up companies that had complementary products and proceeded to integrate these into our product family and sell them through our existing channel.
The problem arose when we started making too many demands of the same channel and diluting the message with too many products or choices. It became harder to capture the mind share of distributors because they no longer had laser focus on one solution. They became distracted by selling “suites” or “platforms” instead of trying to solve real, everyday problems.
We recovered by analyzing which distributors were being successful and why, and which ones were struggling. It became apparent that the solution was to segment distribution into a tiered channel consisting of master distributors, value-added resellers, and system integrators. This allowed each organization to focus on its own strengths and collaborate with each other.
Q: What have you done or what would you consider the best way(s) for Product Managers to improve themselves?
A: I think that the answer to this is to “be the customer” and to “eat your own dog food.” It’s impossible for a Product Manager to be successful without living through the same pains as their customers. No amount of customer interviews, surveys, focus groups, or analysts’ white papers are going to make it real for you as much as trying to solve the same problems faced by your customers. This will give you deep domain expertise. When you speak with customers, you will have a deep understanding of their issues. You will will be able to identify the complete value chain for your products and services and you will be able to turn this knowledge into effective product plans and specifications. You will be able to equip your sales people with the necessary tools to identify, qualify, overcome objections, and close opportunities. Using your own product every day will make you into an expert and will be an eye opener when you get to see all “warts” but also see all the features and value propositions that can be exploited in innovative ways.
Q: Where is the best place for the Product Management function in an organization and why?
A: I think that Product Managers have to have one foot in marketing, one foot in sales, one foot in engineering, and one foot in support. That means you’ll either have to start growing some extra feet or you’ll need to develop relationships across multiple departmental boundaries to help you gather information, come up with pragmatic solutions to problems, and drive product vision through planning into execution. The devil is in the details and if you ask ten persons in your company for product ideas, priorities, or solutions to existing product-related issues, I’m sure that you will end up with ten or more different responses. Position yourself where you can most effectively communicate the product strategy and priorities and develop internal champions that will become your allies in making your plans happen.
Q: If someone told you that they wanted to be a Product Manager what would you tell them?
A: I would first ask them why they want to be a Product Manager and then I would tell them to find senior Product Management professionals that will mentor them and help them achieve their career goals. I think that oftentimes, people have the impression that Product Managers sit around thinking up neat features to stick in the product. Later when they get into the thick of it, they realize that it’s a lot of hard work and that it’s hard to please everybody all the time. You have to balance a lot of different goals such as customer acquisition, customer retention, market leadership, profitability, increased revenues, and many others.
Q: What Product Management tool could you not live without and why?
A: I don’t think that I can narrow this down to a single tool. The tools that I seem to use most often are:
- A good word processor with the ability to create and maintain specification templates to make sure that all necessary requirements are included in each release.
- A spreadsheet to create matrices of various kinds such as feature lists, competitive advantages, product gaps, compatibility matrices, etc.
- A good source control or version control repository that will help all important documents to be centralized, versioned and backed up.
- A good defect tracking system that will help you prioritize and analyze bugs or enhancements and group them together into release vehicles.
- I also use HTML and image editors to create high-fidelity mock-ups of user interface screens or components. This helps me to not only think through requirements, but also to present various options to customers and other stake holders before writing specifications that will need to be changed later because not enough time was spent on requirements in the front end of the development life cycle.
_________
And now for Luis’ question for The Productologist:
Q: What is a good ratio of Product Managers to engineers assuming a top tier enterprise software product company with a third (or later) generation product?
A: The number of Product Managers per product or products per Product Manager is often a topic of discussion in Product Management literature, but the ratio between Developers and Product Managers is less straight forward in my mind. The average is 5.5 developers per Product Manager, but in reality, I think this number varies widely. In fact, I don’t see why the number of Developers and Product Managers should be considered together at all.
For both Developers and Product Managers, the number is primarily driven by product complexity. In early stage products, the number for both Developers and Product Managers is lower because product complexity is lower (Note: this is a generalization; the first release of a product can be very complex, but as a general rule, products start off lower in complexity and become more complex over time).
As the product matures, complexity increases, which usually requires both more Developers working on it, as well as diversification in the areas of expertise for the Dev team. Over time, the product may remain complex, but the Dev effort to maintain that complexity decreases. The effort looks much like a bell curve, though the shape of the curve varies from product to product.
For Product Managers, the number required is driven by different factors, such as domain expertise, number of products and product modularity, and the scope of the position (what the PM is tasked with), and product modularity. Let me explain each of these in greater detail:
Domain expertise comes into play in a similar way for Product Managers as it does for Developers, but for Product Managers, domain expertise revolves around the markets that the product serves vs. the technologies used in the product. Product Managers whose product serve diverse markets need to be able to understand those markets in great detail and that’s not always possible for a single Product Manager. When a single PM can no longer effectively manage a diverse pool of markets, it’s time to hire more.
The number of products that a single Product Manager can effectively handle varies based on the experience of the Product Manager, the sophistication of the the product, and how inter-related the products are. Three products per Product Manager tends to be the average, at least in recent surveys of Product Managers. On the flip side, if the product is very modular (and very large), it makes sense to have Product Managers be assigned to modules within the product. The same rules apply, but for modules instead of products. This can address the domain expertise issue, too, since Product Managers can be specialized for their module(s).
As most Product Managers know, the definition of what a PM is responsible for varies greatly from organization to organization. This is why scope is an important consideration in how many Product Managers should be staffed. A PM that is tasked with many ancillary (but critical) tasks, will have less time to focus on core Product Management functions, than one that is heads down on pure Product Management tasks. This could lead to needing more Product Managers or to bringing in staff that can handle the ancillary tasks.
So, after all that, what do we have? Development and Product Management both need to evaluate staffing based on a variety of factors, but considering the ratio between the two should not be one of those factors.
Luis had a 2nd question about structuring the Product Management organization, but I feel that deserves it’s own post, so look for that in the future.
A bit more about Luis:
Luis started his career in sales, working for manufacturing automation companies. After managing sales teams and being on the road for years, he decided to get “off the road” and stay closer to home to help raise his child. He moved into mergers and acquisitions and was tasked with managing an acquisition that required merging the product lines and channels to bring an integrated solution to market. That opportunity gave him his first taste at Product Management and, twelve years later, he’s never looked back. As a Product Manager, Luis has provided vision and leadership that resulted in long term contracts with global companies including: General Motors, Boeing, 3M, Intel, Nestle, Bausch & Laumb, Philip-Morris, and others.
Popularity: 20% [?]
Related posts
Tags: bug, Customers, Engineering, enterprise, enterprise software, feature, goals, Interface, leadership, Marketing, platform, product management, Requirements, sales team, strategy
1 Comment »
This is a very special edition of the Product Management Reader. Not only does it contain 8 (which is my favorite number, right after 2 and 4) great Product Management blog posts, but each comes from a blog where the word “Product” in the name of the blog. Amazing, I know. And what are the chances that they would be included in a list on another blog called “The Productologist”? Astronomical, I am sure. Please read each of them with the appropriate level of reverence.
- Product Manager – Translator Extraordinaire
[Product Marketing.com]
- Scenario Planning in your Roadmap
[Strategic Product Management]
- How much customer “capital” have you earned?
[Product Management Tips]
- Why doesn’t Engineering report to Product Management?
[On Product Management]
- Searching: Product Management Architect
[Product Management View]
- How NOT to do Win/Loss Analysis part 1: CRM Reporting
[On Product Management]
- Product Managers Can Learn From The Past: The Story Of The Vasa
[Accidental Product Manager]
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: 20% [?]
Related posts
Tags: Analysis, architect, CRM, customer, customer capital, Engineering, Marketing, product management, product marketing, Reporting, roadmap, Strategic, translator
1 Comment »
Back in December, a reader named Adam sent me an email about a book that I had just reviewed, What Customers Want by Anthony W. Ulwick. Adam asked me about my recommendation, which was
“…it’s not a good fit for Product Managers at early stage companies or where there is not a lot of product or market data for you to evaluate under-served outcomes.”
Adam’s question to me was essentially, “Well, if this book isn’t good for Product Managers at start ups, which ones are?” It’s a good question and one that until recently, I would not have had a good answer for. The problem with Product Management books is that for the most part, they are all about process and what can only be loosely defined as “traditional” Product Management.
Traditional Product Management is what we all learned about in Product Management training (Pragmatic Marketing, Sequent, ZigZag Marketing, etc) and read about in books like The Product Manager’s Handbook and Product Strategy for High Technology Companies. Traditional Product Management tends to be waterfall development with teams that have significant resources (Program/Project Manager, anyone?) and an extensive organizational and process hierarchy.
That’s not what most Product Managers at start ups experience. They’re more likely to be just one person, who probably inherited an Engineering team that was accustomed to NOT having any Product Management process. There’s no supporting team members and they also find themselves wearing many additional hats, such as Sales Engineer, QA Engineer, and Technical Writer. For those Product Managers, books that discuss traditional Product Management process are not very useful.
To be honest, the best place to find the kind of information a start up Product Manager needs is on blogs like this one (toots own horn!) and many of the others out there who post regularly about their EXPERIENCES at start ups. I won’t list them here, but check out the list of folks under BlogNation in the menu. There’s lots of great information out there.
However, I recently read (and reviewed) Rich Miranov’s The Art of Product Management and while it’s not they same type of book as the one’s I mentioned earlier, it provides a lot of insights on how Product Management works at smaller companies, especially start ups. I would recommend it for folks who know enough about Product Management to be dangerous, but want some guidance on what happens when you step outside of the traditional Product Management framework.
There are also other books and resources out there that don’t specifically address Product Management as a discipline, but are nonetheless useful for Product Managers looking for information that they can use to build and deliver better products. Examples include Tuned In, Rules for Revolutionaries, Freakonomics, Manager Tools, and The Welch Way.
One big rule for ALL of these resources, including this blog: there is no gospel on Product Management. YOU have to decide what is right for you, your product, and your organization. If something you read or hear or see strikes you as interesting, give it a try. If it works, great; if not, you still learned something.
So, Adam, there’s the long answer to your question. We know you have a choice when you read Product Management blogs and we appreciate you choosing The Productologist. We look forward to serving you again in the future. The local time is….
Popularity: 25% [?]
Related posts
Tags: Anthony W. Ulwick, Customers, early stage companies, Engineering, high technology companies, Manager Tools, Marketing, pragmatic marketing, product management, product management books, product management training, Rich Miranov, start ups, waterfall, Welch Way
No Comments »
Today’s Product Management Question Corner brings us some insights from Mary K. Marsden (she prefers just Mary K), New Business Leader for Retail and CPG accounts at Acxiom, a developer of large-scale enterprise business intelligence and marketing databases. While Acxiom is not a start up in any sense of the word, Mary K has participated in her fair share of entrepreneurial efforts. Read more below about how she leveraged her Product Management experience in CEO and leadership roles.
Q: How did you become involved in Product Management and was it planned?
A: No, this aspect of my career was not planned. When I was working in Marketing Communications at Novell back in 1988, we were growing so fast and having challenges recruiting people our executive team expanded marketing’s responsibility and that is when I got my first leadership role in Product Marketing.
We were divided into 2 discipline areas Product Marketing and Product Engineering. Product marketing was responsible for the market requirements, pricing, release schedules, communicating with Sales, Marcom, PR, product launches, new release priorities, bug fix priorities… We were also responsible for the business case and presenting any new products to the innovation center. Product Engineering defined the most efficient way to develop the product we had designed.
Q: What are the biggest challenges that Product Managers face?
A: I believe the biggest challenge Product Managers face is knowing how to prioritize product functionality. What do customers really need and will pay for. It is easy to fall in love and start creating products and services but will the market value the product and will they pay for it. The balance of development to revenue is a perpetual challenge.
Q: What is your greatest Product Management achievement?
A: My greatest achievement again was at Novell releasing an SDK (software developers kit) in conjunction with Microsoft’s operating system release. Microsoft did not make it easy for partners/competitors to write software to their platform. Getting a product out the door on schedule, that worked was a Herculean accomplishment for our team.
Q: What was your worst Product Management mistake and how did you recover?
A: We developed a computer telephony application that was a “great idea” only we could never get the telco companies to adopt our products. We did not recover and the company failed. We did not understand the market, and we created the product mostly in a vacuum with some input from consumers. We learned a hard lesson on that one; we had raised $1M in venture funding based on our business plan and a rough prototype, getting the money was the easier part getting into the market proved impossible for us.
Q: What Product Management tool(s) would you consider most effective and why?
A: Listening. Listening to the market, your customers or potential customers, your competitors… I know you wanted me to suggest a tool, the tool does not matter if the product team is not listening.
Q: Where is the best place for the Product Management function in an organization and why?
A: I believe the best place is aligned with marketing. Understanding the market, the gaps and the clear needs of the customer are critical to Product Management success. Also the release cycles are so rapid now and most of the debugging is done in partnership with the customer – putting Product Management customer facing is the best for the organization and the customers.
Q: How has your experience as a Product Manager influenced you as a CEO or founder?
A: Having a product management background made me a better CEO it let me focus the company’s resources effectively. We spent our time and money on product features that made a competitive difference. It also taught me how to communicate with my development team and how to architect the solution I wanted without telling them what to do. That gave the team the space to be creative within the needs of the business. My background in Product Management also made me a better judge of time lines. We got the first version of our platform to market on time, that keeps the investors happy and that is important in the very early stages of the business.
Q: If someone told you that they wanted to transition from a Product Manager role to CEO (or founder), what would you tell them?
A: Spend a year or two in Marketing, Marcom, and/or Sales–all the customer-facing functions. You will learn to “hear the customer needs” and be able to translate that into products, and services. You will learn to prioritize and manage the resources of your company much more effectively. Also you will see the gaps in the market and come up with better ideas. Don’t create a product in a vacuum; 9 out of 10 companies fail because they create products no one cares about or ever hears about.
—————-
Mary K’s question for The Productologist:
Q: What is the biggest challenge product managers face in today’s development environment? What company has the best product managers – why, what do they do that others don’t?
A: There are many Product Management challenges, but the biggest one is the lack of consistency in Product Manager roles across (and sometimes even within) companies. There are so many differences in job descriptions, functional responsibilities, placement in the organization, and goals, that it is difficult to make the transition between one Product Management job and another.
Take positions like Account Manager, Marcom Director, or Development Manager. They each have relatively defined roles, responsibilities, and success characteristics. It’s not guaranteed that a Marcom Manager at one company will be a success at another, but the variance in the necessary skills and experience to be a good fit across several companies is minimal.
On the flip side, 20 Product Management job postings could have 20 unique skill sets and experience requirements, as well as be situated in many different areas of the organization. Is the team Agile-based or do they do more traditional waterfall? If it’s Agile, what flavor? These little differences matter a lot. At start ups versus mature companies, Product Management might not even look like the same job!
While diversity is usually a good thing within an organization, it can hinder the development of Product Management professionals by making job requirements so specific that very few candidates are actually a good fit, at least on paper. With that in mind, it’s difficult to say which companies, if any, turn out the best Product Managers. Big companies typically have a lot of process in place, so their Product Managers get a healthy dose of that, for better or worse, but they are also highly specialized, so they lack the broad general skills required in smaller teams. Product Managers at small companies get a lot of experience working directly with many functional areas within an organization, but they don’t get to do many of the purely Product Management tasks because they are spread so thin.
That’s why hiring Product Managers can be such a difficult and drawn out process. It’s a lot like trying to find a good dance partner…it’s not one-size-fits-all.
A little more about Mary K:
Mary K is a proven entrepreneur with over 20 years of experience in global marketing and management with some of the software industry’s best companies. Over the last decade, Mary K has built two successful consulting companies that focused on strategic management marketing and the “smart application and commercialization of technology”. Her clients included leaders in the industry, such as Microsoft, Novell, HP, and Fujitsu. Prior to that Mary K had a very successful management tenure with Novell, Inc. during the rapid growth stage. She has also led the successful commercialization of dozens of software products and rolled-out over 20+ companies in the US, Canada, Europe and Japan.
Popularity: 54% [?]
Related posts
Tags: Acxiom, agile, API, balance, business intelligence, business leader, ceo, challenges, communicate, competitive, Customers, Engineering, focus, Innovation, leadership, leadership role, leadership roles, Listening, Marcom, Marketing, marketing databases, Mary K. Marsden, new product, Novell, platform, prioritize, product management, product marketing, prototype, release cycles, release schedule, release schedules, SIG, software developers kit, start ups, UI
1 Comment »
In this episode of the Product Management Question Corner, I am interviewing Gene McKenna, VP of Product at UpTake, a travel search and discovery site. The next few PMQC posts will focus on Product Managers who have an entrepreneurial streak. They’re founders, CEOs, and exec team members at start ups and you’ll find that they have some interesting things to say about how they approach Product Management and how they moved from PM to bigger things.
Q: How did you become involved in Product Management and was it planned?
A: I’ve had an organic growth from developer to architect, to a professional services role and then formally into Product Management. Product Management is a broad term and varies a lot from place to place. I am more on the product development side than the product marketing side. My path was not all planned from long ago, but each step change seemed like the right decision.
Q: What are the biggest challenges that Product Managers face?
A: I’m reminded of that credit card commercial with David Spade where he keeps saying “no”. If you are a Product Manager, you better be good at that. Lots of people have great ideas, but a great product needs focus and priorities. The challenging part is to keep people from getting discouraged when they hear “no”, so I try to say “yes, in the future” which is really the right answer.
A second challenge can be getting everyone in the business on board with the same process. We embrace agile development and that sometimes poses a challenge for folks who still cling to those heavily detailed project plans and that big waterfall document.
Q: What is your greatest Product Management achievement?
A: I like to think my greatest work is yet to come, but my greatest work to date is UpTake’s industry-first, semantic travel search engine. We spent about two years building a search engine and a back end data collection and organization system whose output is the web’s largest online catalog of travel products. Already, it helps travelers make better decisions by providing them with a summary of the collective intelligence about travel products we recommend. Realizing our full vision and making it a truly great product will be the focus of the next two years.
Q: What was your worst Product Management mistake and how did you recover?
A: Failure to set expectations properly. As a Product Manager, you are always talking about what is coming, what features we will have and how great they will be. There are two ways to mess this up and I’ve done both. First, I’ve underestimated how long things will take and second, I’ve miscommunicated that a concept that might come some day is a feature coming soon. Recovery is a long process of getting it right the next ten times.
Q: What Product Management tool(s) would you consider most effective and why?
A: When people ask me what I do, I answer “I translate and I meet.” I translate from marketing-speak to engineering and back. I translate business requirements to visual and technical designs, and back. And I meet, and I meet, and I meet. For my job there are only four tools I ever really need. Outlook, Excel, google docs and a wiki. I can mock up nearly anything in Excel, with occasional bits of Photoshop pasted in. A wiki that describes what are we doing, why and when is it done, is critical. There are lots of agile development “scrum board” tools, but we’ve found using a simple Google Docs spreadsheet as the focus of our daily stand-up and means of tracking progress works great. And of course, Outlook is important because I need to have a good calendar to schedule lots of face time with pretty much everyone in the company to talk about what we are doing, when, why, what it should look like, which trade-offs can be made, etc.
Q: Where is the best place for the Product Management function in an organization and why?
A: In a corner office with an awesome view.
Organizationally, the answer will depend on the kind of company. Is it a product company or a service company with a product or set of tools? Are there many products or one? Is it a big company or small? Are there separate product marketing and product development functions or are they the same? Generally if there is a business group whose P&L is driven by a product, the Product Manager should either be the general manager of that business unit or should report to him. At a small company, that usually means reporting directly to the CEO.
Q: How has your experience as a Product Manager influenced you as a CEO or founder?
A: I think both my Product Manager role and my co-founder role have influenced each other. The business side says you don’t need the best UI, the biggest set of features or the latest technological doo-dad, what really matters is if you are achieving the business goals. The perspective that being a Product Manager brings to business is a simple, well-honed message and a focus on getting the core parts of what you are doing right.
Q: If someone told you that they wanted to transition from a Product Manager role to CEO (or founder), what would you tell them?
A: Being a Product Manager and a founder/co-founder is a great idea. Go for it. It is one of the best ways to act on the creative drive inside you. Moving from a Product Manager to a CEO means you will need to focus your creative energies on lots of things besides making the best product
—————-
Gene’s question for The Productologist:
Q: The Productologist does a great job of covering a broad array of topics of interest to Product Managers, in all their flavors. What do you see as the core mission of The Productologist? How will you know when you’ve succeeded?
A: Hmmm…while I don’t typically think of my blog as a product, it is. It has features (and bugs) and I have to serve my customers with quality or they will jump to the next Product Management blog and never look back.
When I started The Productologist back in early 2007, my goals were pretty simple: write about my experiences as a Product Manager and contribute to the dialogue about Product Manager professional development. At the time, I thought I had done a fair bit of planning. I did some research on domain names, found a decent publishing platform and a relatively unique template. I even took the time to map out a publishing calendar and wrote about a 6 posts before actually going live.
What I didn’t have was a mission statement or a roadmap for where I wanted to go. I just figured I would “play-it-by-the-ear” (thank you for that Kenyan colloquialism, Lucy Farrell) and see what happens. I thought (and still think) that is fine for The Productologist. The core mission has evolved from being just being focused on my experiences, to getting other Product Management professionals to share theirs, through comments and interviews like the Product Management Question Corner. It may change again in the future, but my plan is to let it evolve organically.
I don’t rely on it for any income (it’s more of a cost center) and it’s not my only focal point, but I do spend a good deal of time thinking about it. I think about how I can extend my reach to new readers or whether my writing is getting any better or whether my early posts stand up to the test of time. I keep thinking about what new features to add or how to make the information more accessible and useful to my readers (and potential readers). It’s subjective, but that’s how I measure its success. And so far, it’s pretty successful, at least in my mind.
If I ever find that I don’t enjoy the writing or managing the blog anymore, or that I don’t get that little tingly feeling when I push the “publish” button, that will be the signal that I’m done.
A little more about Gene:
Gene has 15 years of experience in software design and product development in direct marketing and travel. Previously Gene ran product at Acxiom Digital (formerly Digital Impact) and was responsible for the platform that sent over 5 billion personalized emails daily; during his tenure the company reached profitability for the first time. Before that he co-founded Bluedot Software, a travel company sold to Peter Ueberroth’s Ambassador’s International. Gene is a MIT-trained engineer and has a Masters from Stanford.
Popularity: 54% [?]
Related posts
Tags: agile, agile development, bugs, ceo, communicate, Customers, david spade, Engineering, Gene McKenna, goals, Marketing, organization system, plan, priorities, process, product management, product manager, product marketing, requirement, Requirements, roadmap, scrum, software design, start ups, trade-off
No Comments »
Don’t Make Me Think (2nd Edition) by Steve Krug
I have seen this book sitting on the desks or bookshelves of several designers and UI engineers that I know and it has always intrigued me. The whole concept of making the user experience so easy that it seems obvious is a big task and even with the help of books like this one, it’s still a moving target.
The book is geared toward building corporate and publisher websites, but a lot of the topics can also be applied to applications, both consumer- and enterprise-oriented software. It’s a short book (with pictures, no less), which is good. It’s laid out with some guiding principles around page layout at the beginning and then goes on to more advanced topics such as usability testing and accessibility.
Good Enough
Early on, in chapter 2, the author identifies a fundamental challenge of software development, especially web applications:
“We Don’t Make Optimal Choices. We Satisfice.”
By this, he means that we make trade-offs between making the best possible solution and one that is good enough to satisfy the user or market. Many choices that a Product Manager has to make are based on having to balance between the optimal solution and what can be done in a given time frame with the available resources. We bet that if we satisfice, it will be enough to address the short-term requirement or at least buy some time to refine the feature in a later release.
Krug later identifies some other best practices, again focused on web sites rather than web applications, but many of them apply to both, including the following gems:
- Using common navigation and organizational conventions
The less time users spend trying to figure out about your site/app, the happier they will be
- Limiting the use of text-heavy instructions
If your instructions are more than a few sentences, go back and fix your process or workflow, because that’s where the root of the problem is
- Telling visitors about your site/application
Don’t assume that everyone who arrives at your site/app know what it’s for and what it does
- Creating an obvious starting point
The home page is precious real estate, so there is going to be some crowding; make sure users know what to click
They seem like no-brainers, but both web sites and applications sometimes forget about one or more of them in the rush to create a unique experience of the user in “the next big thing.”
And Now a Word About Users
In latter part of the book, Krug dedicates some space to Usability, a subject that is near and dear to me, but which is often overlooked due to lack of time, space, money, know-how or resource availability. He starts off by debunking the myth of the “Aveage User.” The Average User is a tool frequently used to make trade offs for a website or application. Unfortunately, building software for the average user typically ends up creating mediocre software that addresses no one’s requirements.
Krug also discusses the ins-and-outss of usability testing, drilling home the message that focus group testing is NOT usability testing. It’s great that testing is included as an integral part of design. I have heard (and lived a few) horror stories about re-design projects where 100% of the effort is allocated to page layout and supporting graphics, and ZERO effort on determining if the changes are an improvement over the existing version. Oh, there’s a lot of review and feedback, but it doesn’t come from users; it comes from people within the company, most of whom are NOT the target user.
In addition to the “why,” the author spends a good deal of time outlining the “how” of testing. Beyond just providing the steps to take, Krug provides a sample script that highlights how even a bootstrapped organization can do minimal testing to improve their product.
The book closes with a chapter on how poor usability can zap user goodwill toward your software. We’ve all been there. You go to a site or web application that looks interesting, but after 10 minutes, you are so frustrated that even if the site provided all of the answers to the great questions of the universe, you wouldn’t go back. He highlights some of the most common goodwill killers:
- Hiding information
- Asking for unnecessary information
- Szzle for Sizzle’s sake
- Making users jump through hoops
- Looking like an amateur
Recommendation: This book is one that Product Managers should read once and then give/loan/purchase for their Engineering VP/Lead/Developers. It’s easy to understand, provides both context and supporting data, and it’s short. You (or an Engineer) could read it in one night.
Popularity: 56% [?]
Related posts
Tags: applications, Book Review, consumer, Engineering, enterprise, feature, feedback, goodwill, guiding principles, page layout, process, requirement, Requirements, Satisfice, steve krug, trade offs, trade-off, UI, Usability, usability testing, user experience, web applications, workflow
1 Comment »
|
Entries (RSS)