These questions and answers will serve to lend some clarity to my preferred process and priorities, related to teams building software products.
The premise in the questions posed focused on ideals. While I have explained what I belive to be ideal, based on my experience and contstant study, every situation brings circustances that are far from ideal and call for adjusting the plan to fit reality. I'm very flexible and always prioritize the team and the objectives over my own personal prefereances, in the matters discussed here.
1. How would you describe your ideal product development process?
Ideally, the team building a product is mostly co-located and working similar times throughout the week, most of the time. This minimizes friction in the team's communication and enables rapid evolution of ideas at every phase of the development cycle.
Team Roles and Responsibilities
An ideal team is made up mostly of members possessing a wide range of skills, rather than each specializing in only a single discipline, so that the team can fluidly reorganize as the work to be done changes over time. But this must be balanced against a need for specialization, for areas where mastery and expertise are crucial.
These are the roles on my ideal team, scoped as broadly and loosely as is possible, without losing the usefulness of roles and team structure.
Product Manager
The Product Manager (mapped to Scrum's Product Owner role, as discussed below) must deliver ROI. All other tasks and responsibilities are only in support of that mandate. They usually serve to coordinate with all stakeholders, cast vision for the product, advocate for the user/customer/client, manage and prioritize backlog, and a slew of other things. But the bottom line is this: the PM must deliver ROI.
Business Systems Analyst
If the scope and pace of the product development are limited enough to allow it, the PM should serve as the BSA, writing user stories and helping the team get clarity about details of the features being built during each iteration. But if this is not possible or becomes a bottleneck for development, the dedicated BSA's role is to support the PM in researching and writing user stories, and being available for team members to call on as a subject matter expert for the product as a whole.
ScrumMaster
The ScrumMaster should act as a mirror for each of the team members, helping them to see their responsibilities and contribution to the team accurately. (S)he should also act as a mirror for the team as a whole, helping the team to have a clear high level view of the current objectives and progress being made toward those objectives. The ScrumMaster is uniquely positioned to bring objectivity and clarity, when most of the team may be getting mired in the challenges and frustrations of their respective tasks.
Designers
My ideal is for all designers on the team to be at least comfortable doing experience design, visual design, and even writing copy. In practice, everyone has their strongest skills, and some may be uncomfortable (or even unwilling) to stray outside their core design discipline. But I like to assign a task based on who is the right person for the situation, rather than to whoever has the job title associated with that task. Lastly, I'd love all designers be comfortable checking out a code repository, building/editing the markup for Web UI views, and committing their changes.
Web Application/Service Engineers
Just like I prefer designers to be comfortable moving among disciplines, I prefer that the engineers be comfortable moving up and down the stack and working on different types of code and functionality. Flexible engineers add a great deal of agility to the development process and allow for engineering attention and energy to be allocated most efficiently.
Platform-Native Application Engineers
One case where I would prefer to specialize the engineering roles is for native application development on the product's target mobile platforms (e.g. iOS, Android, Windows Phone, etc) or target desktop platform(s) (e.g. Windows, OS X, Linux). In this role(s), I value focus and deep platform-specific understanding over flexibility, because you have to have a platform expert on the team in order to make the most of the OS and hardware integrations that are possible on any given platform. Without an expert on each native platform, the team is likely to err toward only building a native UI for the pre-existing functions of the Web application, rather than inventing the best new experience possible for the platform.
QA Testers
Doing QA testing for outright bugs is, in the words of the great John Siracusa, necessary but not sufficient. I want testers who are lazy, snobby, and very kind-hearted. They need to immediately recognize when any user job takes too long or is more complex than necessary and be outraged that their time and energy was wasted by the software (i.e. lazy). They need to notice when error message copy is incorrectly punctuated and be disgusted by the error (i.e. snobby). And they need to deliver their findings with tone and context that is palatable for the rest of the team, in whose work they are spending all day finding flaws.
QA Engineers
QA is the other area where I prefer a focused engineer(s), rather than a generalist covering a variety of engineering tasks. Since reliability is vital for the long term health of most products, QA Engineers must focus on building up proper test coverage for the features and functionality currently being developed. Focusing engineering time and attention on test coverage that evolves with the codebase allows the team to properly identify show-stopper bugs related to this cycle's features, which will invariably arise from development done during future iterations. There is a world of difference between catching such bugs before deploying, when tests fail, rather than by actual users filing bug reports in a live environment.
Unlike other engineering functions, which benefit from team members who can move between functions, the role of QA Engineer should be specialized, to prevent the tendency for proper test coverage to fall by the wayside, while the team is focused on finishing the application code for each iteration on time.
Architects
Ideally, no engineer is exclusively playing an Architect role. Rather, engineers who are primarily writing production code are considering, debating, and determining architecture as the product calls for it.
Developing Product Strategy and Vision
Strategy and vision will ideally be developed out of a confluence of three areas of understanding: the problem domain, the market for products addressing the problem, and current software and hardware technologies available as development tools and targets. Deep understanding of each of these enables development of a strategy and vision for the product that maximizes product-market fit, and each of these three areas of understanding is vital to achieve it.
The Problem Domain
Every product is aimed at solving a problem(s) for some kind of user(s). Understanding both the problem(s) and user(s) is vital. Ideally, the some or all of the product team (especially the Product Owner and BSA) will be natural domain experts. But it is likely that research will be necessary for the team to gain proper understanding and even expertise of the problem domain.
The Market
The market is made up of prospective users/customers/clients, all of whom have the problem being addressed by the product. Understanding the market starts by understanding these individuals, the organizations they are a part of, who makes the buying decisions, how budgets are determined, what the typical budget is, what factors are considered in buying decisions, and how often is the buying decision reconsidered (month to month vs. long-term contracts, etc). Also, understanding the market requires surveying and analyzing the competitive landscape, because the product must usually fill a hole in the market, which is not already being by a competing product (could be differentiating by focusing on one feature over another, targeting a different price point, employing a different revenue model entirely, etc.).
Current Technologies
The final area of understanding required to develop strategy and vision for a product is the hardware and software technologies currently available. It is vital to understand all the component pieces of potential technologies, how each can be integrated with the rest, the advantages and disadvantages of each, and the costs associated with each. Product teams must understand all their options, before they can identify which one(s) will enable the best product.
Also, a product team must have a sense of what new technologies will become possible, or perhaps just become more affordable, in the next 6-18 months. And finally, a product team must understand which technologies will become officially deprecated or simply too difficult/costly to purchase and maintain in the coming months and years.
By fully understanding the lifecycle of relevant hardware and software technologies, the strategy and vision for the product can be shaped to both offer the best possible technical solution to the problem, as well as to ensure that the product is affordable and practical to maintain and deploy.
Deciding What to Build and When
The method for prioritization must be customized based on the situation, but I will highlight three along a continuum, spanning from "theoretical value of features" as top consideration at one end to "cost of feature development" as top consideration at the other.
Waterfall In Phases
One method for deciding what to build, and when, is to theorize what the ideal product would be and then begin building full and exact implementations of those conceptualized features, starting with the most valuable. Even though software can be brought to a working state quickly and features are added in iterations using this method, the focus is on executing the theoretical best-possible product, without fully considering the costs involved with each feature.
While I've had some success with this method, the circumstance was far from the ideal I've described above. The team was distributed with literally a 12 hour time difference, so 95% of communication was in writing and had a one day lag, at least. I believe that outside of this situation, where realtime collaboration is very impractical, this method is a mistake for two reasons.
First, this ultimately will lead to wasted work, as features get built out without gaining the full insight that is brought from shorter iterations and actual users giving feedback. Secondly, ROI will suffer on a per-feature basis, because decisions about what to build next don't factor in the insight of the team members who have the specific skills needed to estimate the time necessary tasks to complete each feature. Sometimes a "nine out of ten" (or 9/10) feature requires 5x the resources to implement as a 7/10 feature. This methodology will mistakenly prioritize the very expensive 9/10 feature over the very high ROI 7/10 feature.
Optimizing for Agile
Another method for prioritizing, which I believe strays too far toward the other end of the continuum, flows out of the desire to optimize the product decisions around agile iterations. When focus swings from prioritizing based on usefulness of features to instead prioritizing on ease of development for each feature in the product backlog, the product suffers. This is true even while the team may appear, to various stakeholders, to be making great progress, adding a high quantity of features in each iteration.
This method is usually selected under the premise that it is focusing on creating value for the business. Instead, by failing to prioritize based on what's actually useful for the user/customer/client, the ROI for the business will actually wane while this method is utilized.
Feature Swap-Meet
The ideal method for choosing what to build, and when, is to treat every iteration of development (i.e. what Scrum calls a "sprint") as a trip to a swap meet, where you're looking for a bargain on features, based on their current cost and perceived value. With every iteration, the value of each feature becomes clarified. The process of pulling the bargain features from the product backlog, to plan each iteration, is really a process of negotiation among the team members. Of course features can be chosen based on the currently estimated ROI. But the real value of visiting the Feature Swap Meet during every iteration of development is that features can also be "renegotiated" (simplifying or changing the way the feature will work) to lower the cost of the feature, while still preserving all or most of the value of the feature.
With this method, which is most effective when the team is able to stay in constant communication throughout the development cycle, the team can maximize ROI by using each iteration to get the best bargains possible on features.
Development Methodology
The ideal development methodology will vary based on the nature and scope of the product, size of the team, company culture, and a slew of other factors. And in fact it is unlikely that any strict implementation of a documented methodology would be the best possible solution for any team. But currently, the best template to use as a jumping off point for methodology is the Scrum implementation of Agile. Scrum offers a high level of familiarity and adoption across the entire software development industry, which means less time and energy is wasted just getting buy-in from team members. Scrum also offers a myriad of options for training, to get team members up to speed, and supporting documentation and advice for troubleshooting issues that arise.
Scrum is very thoroughly documented across the Web and in many specialized training and certification courses, but the key aspects of Scrum that I value are these:
No Mandatory Team Roles — Scrum technically involves three roles. These are product owner, team members, and the ambitiously named ScrumMaster. What I value here is that the Scrum methodology does not differentiate between designers and engineers, let alone visual designers and experience designers. The team is simply the people who need to do the work. Any organization beyond that happens as the team self organizes (one of the key principles of the original Agile Manifesto).
Mandatory Face to Face — Another principle of the original Agile Manifesto that I have found to prove out in my career is that face-to-face conversation is the most efficient and effective method of conveying information within a team. Of course, this can now be approximated quite closely by tools like Skype, GoToMeeting, and Hangouts. But the point is that communicating both visually and verbally, in real time, is fundamental for a team to be most effective.
To that end, Scrum mandates whole team face-to-face interaction daily, with what it calls the Daily Scrum or Daily Standup Meeting. While this time is not appropriate to work out actual issues affecting only a subset of team members, it sets both tone and precedent for involved team members to meet face-to-face later to work out issues and collaborate when needed.
Built In Retrospection — Scrum also mandates retrospection at the end of each iteration, which Scrum terms the Sprint Review Meeting. I think of this as what Jim Collins (in his book, Good to Great) called an autopsy. This is a vital step in any area of business, and the fact that it is built into Scrum is hugely valuable to keep the team on track and growing as a unit with each iteration.
2. In your experience, what are the most important characteristics of a good Product Manager?
A good Product Manager enjoys learning and is quick about it. The Product Manager must cultivate his or her own understanding the market, because he or she is ultimately responsible for shepherding the team toward the right product-market fit. The Product Manager should constantly work to gain the knowledge, understanding, and judgment needed as things change, to lead the team to insightful decisions.
The Product Manager serves as a backstop for problems the team runs into and shields team members from anything that will distract them from focusing on their most valuable work. The Product Manager should be naturally empathetic toward users, team members, and management. The Product Manager must cultivate a dynamic understanding of each stakeholder’s priorities, values, objectives, and biases — to be able to mediate between stakeholders on important topics and decisions.
3. In your experience, what are the conditions for success that have to exist in an organization for a Product Manager to be successful?
The organization needs to attract and select the right Product Manager. From that point, it is the Product Manager’s responsibility to create the conditions he or she needs to succeed.