skip to main |
skip to sidebar
In the real world of Agile development, you may be pulled a thousand different ways - and not just by development. Here's a few tricks I've learned to make working with an agile team a bit easier.
1. Plan your stories and epics in advance. Even though the development team is looking at the user stories on the very near horizon, plan a roadmap for what you will be working on over the next 4 quarters. By documenting a high-level iteration plan, it will inform the team on what's coming next, and will help you make adjustments when new user stories are requested. What I've often done is write out high-level user stories several iterations in advance in a spreadsheet (not the acceptance tests- yet). That way I can look at what's coming 5 iterations from now, in both managing my time, and making changes to iterations as they are needed.
2. Keep User Stories Lightweight. At Yesmail, user stories are very simply and include acceptance tests. That (for the most part) is it. By keeping them straightforward and clear in the acceptance test, you'll have less questions from engineering, and more time for managing the product.
3. Be Flexible in the Outcome. When you write user stories and acceptance tests, you probably have a fairly good idea of how the product will look in the UI. My advice? Allow there to be several solutions to one user story - and choose the best as a team. There's nothing worse in really hampering creativity than a product manager with a 'my way or the high way' point of view. That being said, do ensure you communicate the users needs and technical expertise well, so the users needs are well understood.
4. Assess ROI and Market Need. Set time aside to validate your roadmap and backlog with ROI and market need. In my experience, nearly all developers are 'okay' if I communicate that I need time to ensure the user stories are in line with market demands. Practically speaking, this means that I try to make myself available for a few hours to help with product development, but I do say "I will be working tomorrow morning from 8:30-11:00 on a revised market assessment(or other product management task)." Most developers are okay with with working with your schedule.
5. Ensure continual communication about development estimating. In planning the roadmap, I've worked with several development teams to ensure realistic timetables for a product roadmap were communicated. The roadmap answers two questions 1) What do we need to do (and why?), and 2) When do we need it? Ensure that development is on board, and plans for product iterations are realistic. For me, there were standing weekly meeting about iteration planning and estimating. This helps in both building trust both with development teams and executives.
6. Use Steering Committees to Validate the Backlog. What has helped tremendously in agile is monthly explicit communication to the executive team about what's coming in the next few iterations and what's in the products backlog. This may be contained in JIRA, or a confluence page - or a spreadsheet. What's most important is that the team knows the scheduled priorities of the product, and the order in which they are released.
7. Enjoy the ride (and the people you work with). Agile is about daily communication and collaboration. Soo... get to know the development team well. Soon you'll be making a great product with a development team that delivers great solutions and superior products. Agile and agile methodologies are likely to be here a while. So buckle up and enjoy the ride!
I've been noticing a lot of product management blogs that begin "Aack! Development has gone Agile!" Recently I came across "Spotting Fundamental Flaws with Agile" in Pragmatic Marketing's magazine. You'd think we product managers had yet another business challenge and roadblock in front of us because now the development team is getting all needy because they want 'product owner.' Now, truth be told, it's a software methodology, but for us PMs sitting and collaborating with development on the latest products, these changes can have significant impact on our lives.
Agile is much better that what came before it. I've been doing product management for about a decade now. Remember what became before it? Pages and pages of PRDs, detailed technical requirements specifications, 9 month Gantt charts detailing in excruciating detail the development of your product? Do you remember? It was like entering NASCAR with cement wheels. A chasm the size of the grand canyon between product and development. I was directed to talk to the project manager, not development. The black box of months of development/QA/beta testing, that you'd beg to 'get a peak' at before launch. It was awful. My only way to help products get better was to try to forge relationships directly with the development team (beer helped), and talk about the product, and the users, and how great the product could be, then sometimes I'd be able to collaborate better, sometimes my IM would pop up and I could 'get a look.' Then, user testing (if there was any) was so long at the end of the product launch, there wasn't really a chance to change it before the launch date. It was bad. Soo...here's why I like agile.
Agile allows you to respond to market changes quickly. In SaaS software, your 2009 roadmap could completely change by March. Competition, new technical partnerships, business models emerge that may make you rethink what your organization is doing next month. You can completely chance course 2 weeks out in agile, and this was very hard before that. Agile allows an organization to be nimble in responding to market opportunities - and that can make a huge difference.
Agile forces you to think about what's important. One of the key tenants of agile is 'satisfy the customer through early and continuous delivery of valuable software.' Guess who's job it is to ensure what is valuable, and that it's delivered first? Product Management. This doesn't mean you don't have a roadmap, but it does force you to make tradeoffs so the needed features are the next iteration, and the 'nice-to-haves' are in the backlog.
Agile forces you to refine your communication skills about what the product needs. In creating user stories and acceptance tests, you need to both ensure what functions are critical for the next sprint, and what are not. It's light weight, but that forces you to be crystal clear on what you want the product to do. In PRDs, often what was critical was written along side with what was nice to have.
Agile seems to help the creative process of product development. I've been in two separate agile teams at separate companies and even working with different locations, Agile brings a certain level of creativity to development and product that wasn't their before. Being lightweight, it allows better collaboration and creativity with the end product. I think that's a good thing. The best software engineers I've meet have 12 different ways to develop a feature, and have suggestions on how to make the product better. I think Agile gives a process to collaborate creatively on product development.
Again, agile is a software methodology, and in many cases we have a new hat as a 'product owners' (Unless you are a very large companies and have analyst act as product owners). Unfortunately, agile is not by itself, the defacto rule of success in developing great products. We can arm/aid the development team to paint an accurate picture of the user of the product, their technical expertise and needs, and ensure there is adequate end-user feedback, market research, etc to validate the product user stories. Most companies don't have a list of checkboxes to answer "Are you an agile shop?" there's cultural and process changes that need to happen to make it work.
Next up? How I've tweaked my work life and communication style to develop successful products using agile.
I've been buried in research over the last few days, and I've got a few ideas of features that I think would make a tremendous difference to social communities - and consumers- and um...me. This is the 'if I were in product at X social networking site, this would be on my roadmap.
1. Social Network epicenter. I'm lazy. I don't like to have to login to Twitter, Facebook, LinkedIn, Ning, Plaxo, etc, just to post the latest product trend I just found. Think of it like a consumers social networking mini-CMS with a few shared features. Post once, and select where to publish. Phew! My life just got alot easier.
2. Google-like social network search. Why do you have to do a "#" in front of something on Twitter to track it well? (So much for 'Don't Make Me Think!) You should be able to search social networking sites exclusively as well as search multiple social-networking sites at once. Like Google Images and Video, you should be able to search *just* social media sites for things like "Twitter+Virus." Right now, many of the social networking sites don't communicate effectively at all the key asset they have - buzz.
3. My Groupies. Facebook, Twitter, LinkedIn, - you know about me. I've published it (and published more). Can't you use that content to suggest groups that make sense to categorize people, rather than just leave it to us? Like "Would you like to create a Product Management" group?" Who knows? You might even find better revenue streams for advertising if you do. At it's social networking - you could suggest other people I might be interested in.
4. Tag the Influencers - and spread the word. There are people out there that say some pretty smart stuff - on everything from how to eat (well) locally in January, to the best way to do behavioral profiling. Right now finding those influencers is like going fishing, and a continual follow and unfollow. Yuck.
5. Share the love (and my contact lists). Social Networking sites are used by different people for different things. Many have APIs that are open - and I'd like to sync my contacts in each website. So how about using my contact on Twitter to extend to Facebook and vice versa. I don't have email addresses. I have www.twitter.com/lotsofpeople. Make it easier to link them.
Eh-hem. Stepping down from my soapbox. Somebody make these? Please?
For anyone involved in product strategy, one of the key milestones to accomplish is market research. At it's best, it uncovers that diamond in business and market research - an opportunity for a strongly profitable product. At it's worst, it's a bunch of statistics in a sales presentation - after the product has launched because it seemed cool to build at the time.
Looking at the definition of market research on Wikipedia, and you'll get a generic look at primary and secondary research to 'discovering what people want, need, or believe.' That's great, but how do you do it? Market Research FrameworksBefore you begin digging around and buying a bunch of research or conduct your next customer survey you may investigate available frameworks in providing market analysis. Here's a review of a few I've tried...Approach #1: Just dig around and find something good...
Also know as 'What Framework?' This 'dig and report' method is what I started with in product management. It begins:
Executive: "Do some market research around the product."
Me: "Okay. I'll report on what I come up with."
Then for about 3-4 days or more I'm digging through literally hundreds of pages of research on the [Insert Industry here] Landscape , market trends, market dynamics, competitors, and the technology, product and/or consumer landscape. Not only is it haphazard, the outcome is more a business report on "I found out that there's a bunch of information out there, and we have 20 competitors, and have a big market opportunity." While interesting, it is neither providing an opinion on where the product roadmap should be, nor validates some hunches on where a product should strategically be positioned.
Finally, it ends in analysis paralysis - my head spinning with charts, graphs, and statistics. This is why I sought out a framework to investigate market research.
Approach #2: SWOT Analysis
Organizations have used SWOT analysis to assess a product in its competitive landscape. This 'quick and dirty' planning method is great to whiteboard a realistic picture of where your product is, as well as where the competition may head next.
I use a SWOT an analysis to generate and assess the assets and liabilities of a product. So Let's say I have X product. I would look at our product and the top competitors and ask:
Strengths: What are the product strengths that differentiate it from the competition? What organizational strengths do we bring to the table?
Weaknesses: Where are the features lacking or underdeveloped? Are their alliances or organizational weaknesses that erode market share?
Opportunities: Where can we differentiate the product? What strategies can we put in place to gain greater market share?
Threats: How could this product fail? What factors in the market or the roadmap can bring it to obsolescence or loose market share?
In my estimation, SWOT tends to focus mostly on your product and the competitors around it. This framework is bit too close, in looking purely on how an organization can meet objectives set for a product and narrow in looking only your product vs. the competition. Often market research is sought in determining the objectives themselves, and this is where it can be limiting.. .Often the organization looks to product to set the objectives of the product - or at least recommend them. SWOT will not help you set the product objectives because it assumes they have already been set.
Approach #3: The 5 and 6 Forces Model
The 5 and 6 Forces Model look at product as 5 (or 6) key forces that shape a business strategy.
This framework goes deeper into the market dynamics of where you are investigating a product.
Each of the forces are used to evaluate the competitive intensity of a market. If there is intense competition there is both strong interest from potential buyers to purchase a product, and business model(s) that ensure companies make a profit to meet this demand.
The forces include:
1) Competition for your product.
2) New entrants that would compete in your space, often with new business models.
3) End users/Buyers and their bargaining power on influencing price, integration, and concentration.
4) Suppliers of raw materials, components and services for your product and and their bargaining power on business strategy.
5) Substitutes products and those factors that influence it (cost of product, perceived value, cost to switch, etc).
6) Complementary products/ The government/ The public. This 6th factor takes into account either strategic alliances are put in place, and how the government or public can influence business strategy for a particular product.
This is a great framework to investigate what is out there in an industry for a potential product. It's a great whiteboard exercise as well in that it lets you reference the dynamics that are shaping the product strategy.
There are some drawbacks to this approach, however. For example, it doesn't see the relationships in how buyers, suppliers, and competitors work together to influence the business environment. In technology and software for example, there are a myriad of strategic alliances that may cause a buyer to switch - not because of your product feature set, but because your product "plays well with others" (Salesforce.com might be an example). Secondarily, the value of the product seems to be in creating barriers to entry by competitors in this framework, which is not always true (take the iPod for example, low barrier to entry in MP3 players, yet they gained tremendous marketshare).
What Next?
For market analysis, I do both the 6 forces and the SWOT analysis as a framework to start my market research. I'm not by any stretch a purist, but both approaches can uncover some market dynamics that can shape your product strategy, and uncover where market research is needed. This realistically may keep your head from spinning in a bunch of research! Usually the 6 forces first to look for the product opportunity, and SWOT too more closely look at the competitive landscape for a product. These usually uncover where additional market research is needed in investigating a product strategy.
Recently I was asked to give a presentation on how I use twitter in product management. When I first used twitter, I was a bit skeptical. But after I got a great recommendation for a feature rating tool (thanks to @idaapps), a local social media chapter (thanks to @brittanysims), and numerous bits of market research by following my tweeple, I'm a convert.
Posts
