Posts Tagged “challenges”
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 »
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 »
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 »
This edition of the Product Management Question Corner brings us to sunny Los Angeles. We are continuing our interview with entrepreneurial Product Management folks and today’s guest certainly fits with the entrepreneur side of things. Our interviewee is Frank Addante, founder and CEO of the Rubicon Project, an ad network optimization solution. With six companies under his belt, he knows a thing or two about starting companies and building products.
Q: How did you become involved in Product Management and was it planned?
A: In college, I started my first company and I did the Product Management aspect and wrote the code at the same time. It wasn’t really planned; it was more out of necessity. I think I actually bought a book and started building a website from there.
Q: What are the biggest challenges that Product Managers face?
A: Keeping a product simple while continuing to innovate and move things forward is a big challenge. Essentially staying focused on the product and its usability is really important – that’s the ideal way to get around these challenges.
Q: What is your greatest Product Management achievement?
A: I’d have to say the Rubicon Project. To date, our product has helped more than 1300 web publisher customers, and we’ve grown to that number so quickly (we launched in late 2007). What we’ve created is not only a product that answered pent-up demand in the market (optimizing unsold ad space) but also one that is accessible and painless for our customers to use.
Q: What was your worst Product Management mistake and how did you recover?
A: At my last company, StrongMail, we initially focused on packaging too many features together, and we tended to talk so much about how the technology worked and not enough about what it actually did for the customer. So you could say we were a platform that didn’t have any applications. In fact, a customer once said “hey these are great features, but it gives me too much rope to hang myself with.” We started out being way too complicated so we revamped our software and turned it into an appliance so it was a ready to go on a server that customers could plug in and get working right away.
Q: What Product Management tool(s) would you consider most effective and why?
A: PowerPoint – hands down. It’s very simple and easy to convey feelings and thoughts in an illustrative way. I joke that once we make something in PowerPoint then someone has to reformat to PHP or Perl. If we had a PowerPoint to PHP converter, we would be rocking and rolling over here.
Q: Where is the best place for the Product Management function in an organization and why?
A: I think the Product Management function should touch many parts of the organization. First, it should have a presence in sales since this is where direct customer feedback comes from. It should also intersect support, because this is where customers say what they would like to improve while alerting the team to what problems are surfacing. Marketing is also important because this insight will help with the more forward looking aspects of the product. Lastly, engineering is important because this is where the product vision lies and the engineers know what is possible and ways to continue to innovate.
Q: How has your experience as a Product Manager influenced you as a CEO or founder?
A: Everything that I have always done has been very technology focused. And when you create something that solves a pain in a big market, it really drives you. I try to build products that sell themselves and invest my time in getting those things right the first time around.
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: I’d say go for it. A CEO’s role is beyond the product. You have to look at how to market what you’ve created and how to manage it. But you can’t forget that, as a CEO, it’s also very important to manage the people behind the product. Though there isn’t a direct line from product manager to CEO, I think that people who are successful in this area will make good CEO’s.
_________
And now for Frank’s question for The Productologist:
Q: In gathering feedback on your product, what percentage of that feedback should be taken directly from customers and what percentage should come from your gut feeling about the market? Customers don’t necessarily know what they need sometimes, just the problem they need a product to address – do you guide the vision with your instinct?
A: If a Product Manager wants to be successful, they cannot rely solely on creating products based on customer feedback. Customers can be a great source of input, especially early on in the development of your product, but they cannot be the only input or even the primary one. There are many reasons for this, but let me highlight a few of significant ones:
Customers are selfish
They are freely giving of input about what they want you to change or add to your product, but they only tell you what THEY want. They are not interested in whether that benefits other customers or your company. This can be especially dangerous if you have very few customers, since their influence will be disproportional to future customers.
Customers are poor communicators
If you have a good pool of customers, you can mitigate the first hurdle, but you still have to deal with the fact that while they may be forthcoming with lots of details, that information is rarely easy to convert into requirements, or even accurate. What you will hear from customers are their immediate pain points. They will go on about some particular issue that their boss railed on them about yesterday as if it was the single most important thing in the universe. That does not necessarily translate into a feature or may not even be something that your product can or should solve. Even worse is that if you do deliver something to address that issue, they have already forgotten about it because it wasn’t really that important to them in the first place, just the most painful.
Customers don’t know the market
If you can get beyond the two previous challenges, you still have to figure out how the customer feedback fits in with your overall strategy. Sometimes what a customer wants from your product takes you in a direction that is counter to the one the market is going or the direction you want to take your product.
The Product Manager has to synthesize data from many sources–customers, prospects, competitors, industry leaders, analysts, and their own gut–in order to make (or keep) the product successful. The customer is one of those, but not the only one. Sometimes you even have to tell the customer that you are NOT going to build what they want. That’s a post for another day.
Now, back to the original question…there is no magic ratio for balancing the many inputs. A lot depends on the industry or vertical that your product serves, as well as your own experience. Outside feedback and gut-feeling can be equally effective or ineffective. Outside feedback LOOKS a bit more quantitative, but it’s not really. Experience makes it easier to chose one over the other for any given situation, but there are never any guarantees. I like the gut-feel approach, but it’s difficult to justify, and when you are wrong, there is nowhere to point for the failure except yourself.
A little more about Frank:
Frank is a serial entrepreneur with one IPO and two acquisitions before the age of 30. He previously served as the CTO and Founder of L90, Inc., a publicly-held Internet advertising company that was acquired by DoubleClick. He also invented adMonitor, one of the Internet’s most successful advertising platforms for Global 2000 companies. At its peak, adMonitor delivered over 8 billion ad transactions per month for over 3,000 customers, reaching 65% of the worldwide Internet population and producing over $75M in revenues.
Frank was named Ernst and Young Entrepreneur of the Year Finalist and has been quoted in publications such as Forbes, MSNBC, Red Herring, InformationWeek and the Los Angeles and Silicon Valley Business Journals. He serves on various boards of innovative technology and marketing companies and received his education in electrical and computer engineering at the Illinois Institute of Technology.
Popularity: 25% [?]
Related posts
Tags: ceo, challenges, Competitor, Customers, entrepeneur, entrepeneurial, experience, founder, Frank Addante, product management, Prospects, Requirements, strategy
3 Comments »
The end of the year is a time for reflection (and so frequently, hasty efforts to catch up). In between all the hustle and bustle of the last few days of 2008, take some time to count your accomplishments, cherish your blessings in life, and examine your challenges. Life, like Product Management, requires understanding the market, identifying some requirements, and measuring how well you met those requirements. Then you start the cycle again for the next release. Make sure YOU are ready for YOUR next release.
No more posts from me, save a few twitters here and there, but there’s already some great stuff in the pipeline for 2009 including some more Product Management Question Corners and book reviews. I’ve also gotten a few questions via email, so I will put some posts together around answering those.
To all my readers, old and new, thanks for tagging along. May we all have a happy, healthy, and prosperous new year.
Ivan Chalif
The Productologist
Popularity: 29% [?]
Related posts
Tags: Book Review, challenges, Ivan Chalif, pipeline, product management, reflection, Time, twitter
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 »
Psst…Hey kid. Wanna learn a little somethin’ about Product Management? I know a guy who knows this guy who can help. He went to one o’ dem fancy bidness schools, ya know, the one in Chicago. No, not that one, the other one. Then he got hisself a job at some big company in Seattle. No, not that one, the other one. He moved ’round a bit at dat place, learnin’ tons of’ stuff ’bout how the retail bidness works. If you want, I could introduce youz. Be careful though…he talks a lot.
Q: How did you become involved in Product Management and was it planned?
A: Originally I was a financial analyst, before business school. This gave a good grounding in attention to details and focus on the cash flow as the ultimate measure of success: how a business makes money.
I went back to b-school to move into technology product management. Kellogg gave me a great grounding in the cutting edge issues facing businesses. I was recruited by Amazon.com and joined them in 1999. I started off as a Product Manager in the Books retail team at a time when the goal was Get Big Fast. I spent time in several other teams in a variety of Product roles, managing a range of features and services from Shipment Pricing to Transaction Feedback (satisfaction/reputation systems) to Platform Seller Tools to Fraud Investigations Operations.
After 7 years at Amazon, I left in 2006 to join the exec team of uTANGO as SVP of Product Development and Operations. We developed and operate the world’s richest consumer credit-card rewards platform, driving lifetime loyalty while rewarding members up to $1 million over the long term.
Q: What are the biggest challenges that Product Managers face?
A: Product Managers work on shaping the features and services of the company to execute the corporate strategy. All too often it is a challenge at the end of the year to demonstrate the true impact of what was delivered. Either analytics/data instrumentation is left out completely of the feature set, or it is one of the first features triaged if the schedule is at risk. However, having a clear sense from the start as to what the specific measure of success is for a project can help clarify decisions all along the way.
If the team knows that the key metric to evaluate the impact of a project is Revenue per Member Month, or Revenue within 7 Days of New Acquisition, then it enables them to make better trade off decisions for the scope of features and how to optimize them. And at the end of a project cycle or at annual review time, you finally have some concrete metrics to point to for the impact on the business.
Q: What is your greatest Product Management achievement?
A: I have worked on well over 60+ release cycles over the years, but one of my favorite projects was the Amazon Transaction Feedback System. This is a key measure of buyer satisfaction with their transaction from Amazon’s 3rd party marketplace, where buyers rate their satisfaction from 1-5 stars and an optional short note. It is a critical data point for Amazon, as it is a strong predictor of repeat purchases by that buyer, a strong indicator of the quality of performance from the 3rd party seller, and an important consumer review for future customers in the marketplace.
In 2003 I took over ownership of the Feedback system. It had originally been launched as part of the Amazon Auctions platform in 1999, and mostly was a reflection of the eBay feedback system at that time. Buyers rated sellers and sellers could rate buyers. All the feedback from either role was included in the Reputation of the seller, which included all feedback ever received in the life of the account. Over time the Amazon Marketplace (fixed-price retailers) grew exponentially, where the vast majority of the transactions were from established sellers. The feedback system needed to be overhauled to serve the strategy of a high-trust marketplace where buyers know up front what kind of experience to expect from the seller. Similar to the eBay world, the vast majority of feedback Sellers left for Buyers was Positive.
In the Amazon world, the transaction payment was immediate, so there really was no meaningful criteria for evaluating the buyer. But if the buyer account later wanted to sell an item, their account feedback was overwhelmingly positive, when the reality is that they had no reputation yet as a seller. And from the Buyer side, they often were afraid to leave negative feedback for the Seller for fear of retaliatory negative feedback on their own account. So we were getting an overly biased view of the transaction from both sides.
The last problem was that the mathematics of the 1-5 stars made it hard for prospective buyers to clearly distinguish a mediocre from a great seller. Most feedback is at the extremes, not a normal distribution. So while a 4 star movie may be a good movie, a 4 star seller most likely has 80% 5 star and 20% 1 star. Any business disappointing 20% of their buyers is not worth using.
To tackle this challenge, we had some great designers work with ways to change the display of information. We ultimately retained the 5-star rating system, as Buyers were already educated in how to use it to rate their experience. We needed to tweak how this translated into the seller reputation.
Every seller has their Feedback appear in line with their Offer for each product on Amazon. We added the % Positive (4 or 5 star) as well as the count of Feedback, so that buyers can compare 100% positive 1 feedback versus 96% positive 123,512 feedback.
We also changed the duration of the primary feedback calculation to be past 365 days instead of lifetime (what have you done for me lately?). On the seller’s profile page, we broke out their relative positive, neutral, and negative performance for a range of periods (30 days, 90 days, 365 days, and lifetime) so that they buyer who wants more info can gain a sense of recency.
These changes initially launched in the US and eventually rolled out to all Amazon marketplaces around the world with billions of page views to date. The end result was a strong incentive for merchants to take care of every customer to improve their seller reputation, as good sellers attract even more buyers through their positive feedback. And poor sellers either quickly identify their problems and fix them, or fade away. Either way the buyer satisfaction rate (and likelihood of return visits) for the marketplace rises.
I must say that I was happy to see the validation that eBay announced this year (5 years after we launched this) that they were changing their feedback system in very similar ways. Their previous system was not necessarily bad, it was designed to force peer-to-peer auction transactions to work through their problems rather than evaluate unbiased buyer satisfaction with their transaction. And as eBay’s strategy has evolved to take on more fixed-price transactions, their feedback system was not serving this goal.
Q: What was your worst Product Management mistake and how did you recover?
A: Ironically, my worst product management mistake was from this same Feedback project. Sellers on any marketplace are extremely sensitive to how their business and reputation is displayed on the marketplace. And we implemented material changes to the feedback system.
We had conducted seller and buyer focus groups along the way, and had discussed some of these changes, but once sellers saw the final release product they were extremely upset by the change of the primary feedback rating from Lifetime to Past 365 Days. Amazon’s long-time sellers had amassed a significant count of feedback, which they viewed as part of their ‘brand’ on Amazon to differentiate themselves from newer sellers.
In fact, a few of these older sellers were the prime reason why we changed the duration, in that they built up a great reputation years back, but since have been sliding on their performance and have not been very good in the past year or two. I had misjudged how important this longevity display was to the sellers. To address this, we were able to make some minor tweaks to the display on the Offer pages to add the Lifetime count of ratings. The feedback score was still based on Past 365, but we added the information that allows the consumer to gain a sense of the size of the business beyond just the past year.
Q: What Product Management tool(s) would you consider most effective and why?
A: Feature Prioritization Matrix. This is a tool from my Six Sigma background, but it extremely useful in Product Management to ensure that the strategically most important features with the biggest impact are delivered first.
Many times I have seen development teams get sidetracked by the lack of a clear set of strategic priorities. They deliver the features they believe to be the most important, but their unstated criteria may not match up with what the executive team is expecting. Or one key stakeholder is pushing for a feature that is important on one aspect, but may not be the most important one to deliver at that time. The Feature Prioritization Matrix gets everyone on the same page as to relative importance and relevance to the overall strategy.
We develop features using the Agile Development approach of small, iterative development sprints that deliver functional code every cycle (usually 4-6 weeks). To ensure what we are delivering is aligned with our strategy, we have a backlog of features and services that are classified in our Prioritization Matrix. Identify the top 4-5 aspects of your corporate strategy. For our business we focus on Member Acquisition, Drives Revenue, Supports Members, and Platform Scalability. There can be many more, but the key is to focus on the most important elements of your strategy, not all possible elements. We then assign a relative % weighting to each strategic area that sums to 1.
We use excel to track the feature description and the high-level classification of the feature (member marketing, analytics, merchandising, transactional systems, infrastructure, etc). Our tech team estimates a rough Scope Of Work in terms of Developer Weeks.
For each project, we then rank from 0-5, with 5 the highest, what the relative impact is of that project in each strategic area. From all this we can compute a weighted average Value of the project and by dividing this by the Scope Of Work, we can compare a rough return on developer investment. Ranking these in descending order gives a great first pass at what projects would return the greatest return AND support your corporate strategy at the same time.
As these figures are just rough estimates, the computed rank is not expected to be a precise final word on the order of projects, but it is very effective for order of magnitude impact of a project in comparison to other potential features. When a key stakeholder is pushing hard to get their features moved to the top of the list, there is a defensible, objective ranking that was already agreed upon from top management.
Q: Where is the best place for the Product Management function in an organization and why?
A: At Amazon, there are a wide variety of roles that all may hold the title of Product Manager, ranging from close interaction with software development teams on feature specification, to ongoing management of operational business lines with profit and loss responsibility.
I believe that any firm developing products and services needs the Product Management role in the team that is prioritizing and executing the evolution of their value proposition against their strategy. So if their value prop derives from creating new products and services, then Product Management needs to be in the development team.
If their value prop comes from bundling together 3rd party content, applications, or services, then Product Management should sit in the supply chain or vendor management teams.
If the value prop emanates from the power of granular marketing and personalization, then the Product Management should sit in the Marketing team. But regardless of where the desk is, the role of a Product Manager is to connect all these areas to ensure that the strategy of the company is aligned with the features and services delivered to customers.
Q: How has your experience as a Product Manager influenced you as a Senior Exec, CEO or founder?
A: As a senior exec, I use my Product Management background to ensure that all features and services we develop include a clear measure of success, and a hard requirement for data instrumentation. Also, having an understanding of how the systems operate gives you insight to challenge responses of “it can’t be done.” It allows you to distinguish between “can’t” and “don’t think it is worth it.”
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: Get as much exposure to all key stakeholders as you can. Go on sales calls with key vendors or clients. Get behind the glass for user focus groups. Understand the needs of the customer and ensure that the corporate strategy is in line with it. And ultimately understand the metrics of the firm. Know how you generate cash flow, not just how you book revenue (there is a significant difference).
—————-
Sean’s question for The Productologist:
Q: With the passage of a number of privacy laws around the world, including further clarification of CAN-SPAM, what should Product Managers and Marketers do to ensure that they can continue to communicate with their customers across any medium?
A: With or without the more stringent privacy laws and across all communication channels, there are two facets that are key to sucessful communication with customers (or members or subscribers): permission and relevance. If you only have one of those, you are doomed. And, it cannot be the lowest common-denominator, either.
Anyone who has been involved in customer communication in the past 5 years is probably familiar with these, but in my experience working many companies that use email to reach their customers, most will go only so far as to fulfill the minimum requirements of one or the other (or even both). And then they are surprised when their response rates are low and their unsubscribe and/or complaint rates are high.
My friend and former co-worker at StrongMail Systems, Spencer Kollas, wrote a great article back in August 2008 about this exact problem and what marketers can do to fix it. The hard part is that fixing it often requires more time/effort/money than just dealing with the fallout. In the short-term. That looks fine on a spreadsheet when you have to request/justify your spend for marketing communications, but in the long run, the marketer is DAMAGING their brand and their reputation.
Online communications are so easy to metric that marketers can lose perspective on the fact that performance metrics do not tell the whole story. Nowhere in that click report does it show how frustrated a customer is when they receive an email encouraging them to buy a product they already own. It doesn’t show how many friends/co-workers/family members they complained to about volume of email or irrelevance of the content they receive from your company.
Regardless of the topic of your message, customer communication is a service-industry. The marketer who provides poor service to the customer is going to get a bad tip (i.e., fewer clicks/revenue), but even worse, they could get a bad review for their company. I doubt that looks good in a spreadsheet, no matter what type chart you use.
A little more about Sean:
Sean has been the SVP of Product Development and Operations at uTANGO since 2006. He has twelve years of business experience, seven of which were at Amazon.com in a variety of strategic ecommerce roles across software Product Management, retail management, operations, vendor relations, and consumer trust.
During his time at Amazon.com, Sean co-authored two patents (patent pending) in the areas of dynamic-pricing mechanisms and vendor-performance algorithms, and became a certified Operational Excellence Six Sigma Green Belt. Sean holds an MBA from the Kellogg School of Management at Northwestern University and a BA double major with honors in Business Economics and Political Science from the University of California, Santa Barbara.
Popularity: 50% [?]
Related posts
Tags: agile, agile development, amazon, b school, challenges, Customers, eBay, email, executive team, feedback, financial analyst, Launch, lifetime loyalty, Marketing, measure of success, metrics, mistake, performance, priorities, Prioritizing, product management, product manager, release cycle, release cycles, reputation systems, Requirements, software product management, sprint, stakeholder, utango
2 Comments »
Today’s episode of the PMQC includes responses from Emily Kubec. Emily is a product manager at eBay (UK) Ltd.
Q: How did you come into the role of Product Manager and was it planned?
A: A team I managed at Digital Impact were heavy users of an in-house application that had started to accumulate largely any function in the company that required a UI. We needed to rationalise what was in the original product and break off inappropriate tasks into a new one. My manager at the time had the foresight to move me from being the most vocal advocate for user needs to being the product manager for that tool. From there, my role grew to cover more, and more externally-facing, products.
Q: What are the biggest challenges you have experienced as a Product Manager and how did you overcome them?
A: An ongoing challenge is managing the balance between global input and rapid progress. The fastest way for us to get something to market may be for a small American team to propose a single, simple design, but that approach fails as soon as the solution must be adapted for international markets. A large part of my role, then, is less leading development directly and more influencing teams to build a global solution that’s flexible in the right places. Often this means partnering with colleagues in other international offices to make our case stronger. Even more effective is sitting with the US team while the solution is defined, but given the relative scale of our local office, we need to choose carefully which projects warrant that much attention.
Q: What was your worst Product Management mistake and how did you recover?
A: The most dangerous habit I had early on was designing in isolation without developers’ input, largely in an attempt to save time. While I still trust my instincts, it’s proven crucial to have early feedback from an expert who might identify a faster or more elegant way to solve the problem. Keeping that dialogue open is not only better for the product; it’s better for job satisfaction since it’s a rare developer who pictures himself purely as a code monkey and not as a problem solver. Perhaps most importantly, when time pressure is a factor, early engagement builds a level of investment that is indispensable while deadlines loom and resources are stretched.
Q: If someone told you that they wanted to be a Product Manager, what would you tell them?
A: I’d ask them what they really mean by Product Management. There are so many dimensions to what we do, so many continuums on which to define our role. Product Management can differ by company, by office, by product line, by project. I’m happiest when I’m more owner than influencer, and more technical than marketing, but many of my colleagues would disagree. A successful Product Manager must be prepared to wear many hats—and hope that most of those hats fit most of the time.
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: Social networking is clearly hot right now, and many companies are taking a stab, mostly unsuccessfully, at monetising it. SocialMedia Networks founder Seth Goldstein was quoted in MIT’s alumni magazine (Technology Review, July/August [NOTE: requires free registration], “Social Networking Is Not a Business”) as saying that the space to monetise is not alongside content on social sites; it’s “between users”. I believe that, and I would love to work on whatever product really solves that problem seamlessly. On perhaps a more practical note, the DVR interfaces here in the UK are not great, and it’s not clear to me why they can’t be as good as the ones in America. I’d love to work on Sky Plus at least long enough to get it to parity with the TiVo I left behind.
—————-
And now for Emily’s question for The Productologist:
Q: As companies grow and careers advance, Product Managers often begin managing other Product Managers. Is it possible to sustain a balance between being a good people manager and staying involved with a product, or must one of them become dominant over time?
A: Career growth is not commonly considered a problem, but in Product Management and other fields, there is a point where the individual has to choose whether they want to remain an individual contributor, with their hands deep in the day-to-day tasks or a manager, where they can assume a role of greater responsibility, but sacrifice the being involved in the details of the product.
To be sure, there are draws to being a manager:
- Perceived as having greater experience, both inside and outside of the company
- Higher visibility within the company
- Usually has a higher pay grade
- Comes with direct reports
- Appears to be more strategic
But there are also some drawbacks:
- Requires delegation rather than execution
- Requires navigating corporate politics
- More administrative than most people realize
But just because you are a star Product Management individual contributor, there is no guarantee that you will be a star Product Management people manager. The skills necessary to be successful in each role are different and people management is not for everyone. It is possible to transition from individual contributor to people manager, but part of making that transition is letting go of the deep involvement in the product that star Product Managers love.
It is possible to balance the between pure Product Management and Product Management management, but it’s not likely to serve you well in making the transition to management. You’ll be happier (and more successful) if you think of being a Product Manager and managing Product Managers as completely separate jobs.
A little more about Emily:
Emily is a Product Manager at eBay (UK) Ltd, which she joined following her move to London from eBay headquarters in 2005. Now in her fifth year with the company, she is currently a part of the Finding team (search engine logic and results set navigation) but in the past has looked after other areas from mobile applications to fraud detection. Prior to eBay, she spent five years at Digital Impact (now Acxiom Digital) in San Mateo, Calif., in Product Management and Quality Assurance.
Popularity: 40% [?]
Related posts
Tags: balance, career growth, challenges, feedback, international markets, Management, mistake, product management, skills
1 Comment »
In this first edition of the PMQC, I’m interviewing Glenn Mar. Glenn is the Sr. Director of Product Management at Mediaplex, an online ad serving and publishing system.
Q: How did you come into the role of Product Manager and was it planned?
A: I find that doing “soup-to-nuts” software development has been an indispensable background for Product Management, as the latter has been essentially the same work (up to the coding). I frankly don’t know how people without that background get the sensibility for writing requirements that are engineering-facing. It wasn’t particularly planned, so much as I got drafted into a role that obviously needed doing and that I was capable of.
Q: What are the biggest challenges you have experienced as a Product Manager and how did you overcome them?
A: At the front end, Product Management has more client relationship-building and defining your own requirements based on my guess about the market. The former comes naturally to me, but the latter is still a challenge. I don’t find it realistic to make meaningful revenue predictions about new features, so instead I talk to enough people to be convinced that the direction is sensible. It should make sense competitively, be compatible with our current products, and pass the “sniff test” of impact.
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: I’d be Product Manager for major league baseball, and the first thing I’d do is ditch the DH. It’s an abomination.
Q: What is your greatest Product Management achievement?
A: Well I can’t mention the client by name, but it’s our largest client, and I was able to turn the requirements in a direction that favored us (and in my honest opinion, the client’s greater good) and then successfully install and migrate the largest integration project I have been in charge of anywhere. I think it’s kind of funny that this was by far the single biggest financial achievement ever done at Mediaplex and yet I was not voted “Employee of the Quarter.” It just goes to show you that peer voting has a lot more to do with exposure and lack of complexity of the accomplishments as anything else.
Q: What Product Management tool could you not live without and why?
A: We’re not big into the tool set, but I’d have to say Bugzilla (Bug/enhancement tracking system) because the hardest thing it is to get people to do is to leave a usable paper trail.
—————-
And now for Glenn’s question for The Productologist…
Q: I believe there’s a big overlap in what Mediaplex calls “Product Management” and tasks that other companies might put under Engineering, Sales Support, and Product Marketing, not to mention Training, Customer Support, and Tech Writing. How do you think a Product Manager should best position his/her skills in multiple areas so that others understand the finer details?
A: No matter what size organization you are in, Product Management is a multi-disciplinary role. At larger companies, the Product Manager role may be highly specialized, focusing on a single product and only being responsible for gathering and prioritizing requirements. At a startup, the Product Manager can be responsible for those things, plus writing user documentation, running demos for Sales, answering RFPs, being a QA tester, and many other tasks related to the product, but not traditionally owned by Product Management.
To be prepared for either end of the spectrum (or somewhere in between), Product Managers should not focus on developing those specific skills, but rather the more general skills that can be applied to the specific areas. Those general skills (and let me be clear, these are not general in the sense that they are low-level and easy; they are general in the sense that they are broad) are writing, listening, speaking, and presenting (and there is a difference between the last two). These are the core skills of a Product Manager. If you can master those skills, you can apply them to any tasks that you may be assigned, regardless of whether those tasks are traditional Product Management tasks or more tangential ones.
A little more about Glenn:
Glenn had a 13-year career at Pacific Bell that started in computer operations, but developed into a software engineer and sometimes team lead role. After that, he spent a couple of years contracting as a software engineer doing Y2K-related work. When the dot-com explosion happened, Glenn ran into a former colleague who worked for Mediaplex and brought him in on the Customer Support team. In his own words, “The Peter Principle applied and I quickly rose to the level of my own incompetence, the boundaries of which I stretch to this day.”
Popularity: 43% [?]
Related posts
Tags: challenges, multi-disciplinary, product management, requirement, skills, software development, tools
No Comments »
Folks, we’ve got a really great show for you tonight. Johnny Travers and his singing salamanders are here and later you’ll hear the comic stylings of Johanna Elenore Quiznot, but first, take a look at these postings from around the Product Management world…genius, just genius.
- You Don’t Really Own Your Roadmap
[Product Beautiful]
- Musical Chairs
[On Product Management]
- The Product Management Manifesto
[Write That Down]
- The Software Product Management Blues
[On Product Management]
- UX and Product Management
[Commadot.com]
- What are you selling? Product, category or need?
[Product Management Tips]
- Should I get product management certification?
[Ask a Good Product Manager]
- The leadership role of product management
[Lead on Purpose]
- Challenges of Off-Shored Product Management
[Confessions of a Digital Immigrant]
- Requirements data: Use cases, not features
[Forrester Blog for Technology]
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: 72% [?]
Related posts
Tags: art, blog, challenges, feature, HR, leadership, leadership role, management certification, management tips, Manifesto, product, product management, product manager, productivity, purpose, requirement, Requirements, roadmap, software, software product management, technology, UI, Usability, ux, viewpoint
No Comments »
|
Entries (RSS)