Agile Product Management, Marketing, and More
Product Management
Startups and Product Management
Oct 11th
As I spend more time in startup-heavy Austin, I think more about the role of product managers in startup companies. In most cases, that role is implicit–there is no “product manager,” per se, but rather a CEO and/or CTO who have a vision for a product and who chair a personal quest to bring it to market. There is plenty of risk here for those who understand product management and have delivered products to market.
The fact is that as demands placed upon a startup company mount, the focus of the CEO begins to split to operational and technical issues. If someone is not dedicated to the product itself, it seems very easy — to cite but one example — to experience feature creep where people think additional functions “can’t hurt,” while they’re really not focused on the specific target market and whether or not that target market will actually use the feature being considered.
In a recent On Product Management post and the related comments, several of my peers argue for hiring experienced product management early in the life of a startup to avoid missing the target and delivering a product that isn’t a winner. I hereby add my “ditto” to those opinions.
Internal systems
Aug 30th
One of the takeaways I’m finding in Bill Jensen’s book Simplicity is a reaction to the effect that information overload has on company productivity. As there is more and more information to process to do one’s job, it becomes ever more important for a company to provide tools that not only provide access to information, but which help interpret the information in the sense of analytics. So how does this manifest for a large company aiming to produce streamlined products for the marketplace, that will address (and solve well) a specific problem?
As a product manager with a multinational corporation, I find that (at least at my company in my specific division/subsidiary) there’s a contrast between the streamlined solutions we’re being asked to produce, and the cumbersome internal systems we use to collect and analyze the information we use to design such products. The systems we’re building are “push,” but the systems we use internally are “pull.” Some of this may be due to our company’s implementation of off-the-shelf requirements management and project management tools, but the net result is that the company does not make it easier to easily understand the decisions we need to make, much less make them.
I suspect we are not nearly the only ones.
One of the products I’m developing now is a service which can run client-server or on the web, in order to maximize the base of customers to whom we can provide a solution. I’m finding that questions about–and design of–the internal management components to be used by company support representatives are getting short-changed due to the pressure to meet release targets. This is certainly not unique to this one product, and the support angle hasn’t been ignored, but at the same time the support team’s “use cases” have not been considered with nearly as much diligence and interaction design as the product itself. So in one sense, the sub-optimal experience product managers have with requirements tools is being propagated to the experience support reps will have with service management.
Something I need to reiterate within my organization.
Simplicity
Aug 23rd
I started reading a book about Simplicity titled Simplicity: The New competitive Advantage by Bill Jensen, and immediately one of the author’s assertions struck a chord. One of the book’s hypotheses (simplified) is that knowledge workers spend too much time figuring out what to do, leading primarily to diminished productivity and frustration. For large companies, much of this is laid at the feet of upper management, who may craft a concise strategy at the top but fail to disseminate that strategy appropriately within the organization.
In the case of product companies, whose effectiveness is related to how well they can develop new products and bring them to market, this is one function of product management. Product managers are responsible with becoming intimately familiar with the market’s needs in order to identify opportunities to build solutions the market will pay for, and documenting those problems and needs as requirements. (as opposed to building something we think is cool, and then struggling to find buyers)
With this role as market spokesperson, the product manager guides designers to craft a solution that will satisfy the needs so completely that buyers will be lining up to pay. In some organizations, the product manager serves as the designer as well. Either way, when that design is delivered to development, the vision, goals and solution must be clear enough that the developers can craft an accurate plan and execute without getting mired in confusion and endless analysis paralysis. Certainly the feasibility of the design must be validated before the project team is ankle-deep, but much of the programmer-as-knowledge-worker’s confusion can be alleviated by a clear vision of the solution.
Note: Modern design patterns tell us the product should also be simple and focused, but that is a topic for another post.
Jensen cites his research to assert that the 4 primary causes of confusion among knowledge workers are:
- lack of integration of change
- unclear goals and objectives
- ineffective communication
- knowledge management experience
Certainly the integration of change is a big problem during merger and acquisition activity, forcing disparate systems to be blended. Knowledge management is the problem of finding knowledge already present within the organization. But the other two–unclear goals and ineffective communication–can be addressed within a software development organization by product management.
Contact info
Jun 8th
I have to admit, this post rang true for me. When I go to find contact information for a company, and I run across a contact form that keeps the operator masked behind a cloak of anonymity, I typically find myself annoyed. This post helps to explain why.
Sorry this one’s a bit short, but I thought the article is worth a read.
So many products, So few solutions?
May 17th
Healthcare IT is on the minds of many as federal funding is being waved like a carrot to optimize Healthcare IT by 2014.
One important question is why, given that there are any number of vendors already marketing electronic medical record (EMR) products, this area is considered to be so lacking? Is it that physicians aren’t adopting these solutions, or are the solutions that exist not meeting the needs of the market (and, in turn, the American healthcare consumer)?
I believe it’s both. I also believe it’s far too big a problem to cover in one post, much less one blog. Or book.
Adoption rate of electronic health record (EHR) and EMR software is nearly 40%. A number of factors are acknowledged to play into this, both at the practice level (cost, perception of expected productivity gain, physical space) along with legal and business reasons such as ownership of the EHR itself and competition. Certainly there are more, and I make no claims that this is an exhaustive list.
I do find it interesting that several of the reasons in this non-exclusive list are related not to the technology itself, but rather to fear: fear that (without committing fully to the EHR implementation) the productivity gains promised won’t be realized, fear about the legal repercussions of collecting cross-provider data into one record, and fear of making it too easy for a patient to go elsewhere.
Sam’s club is attempting to address the cost concern, and the federal stimulus money should help with this barrier. Technology continues to evolve into smaller, more targeted form factors and purpose built devices – this trend promises to address concerns with space in the clinic, and fitting office technology into a clinical setting.
One overarching challenge is that even if we overcome all of these factors — including the fears of legal and competitive concerns — and doctors all get on board and decide to share their patients’ information in the interest of improving care, there is an underlying challenge with transferring information from practice to practice: semantics. From practice to practice, a condition or a treatment may be coded with similar but unequal terms. Either these unequal terms must be linked to the same code to allow the system to resolve the discrepancy, or the system must learn to interpret the language well enough to identify cases where distinct terms are not equal and when they are. Otherwise, what is delivered from one practice to another must be displayed to the clinician for translation and action, rather than acted upon automatically.
So what’s the solution? Is the problem technological or interpersonal?
Quality Products and Product Quality
May 12th
I changed my tagline today, and I wanted to write down what I meant before I forget. 
The motivating factor behind every purchase is a need that a person seeks to fulfill. It stands to reason, then, that a product that fails to meet the need it claims to fill is not a quality product. Whether that’s because it’s designed poorly and doesn’t accomplish much of anything, or because it is designed well but meets a different need, if it fails to meet the need the buyer purchased it to fill, it is not a quality product to that buyer. Across the chasm, once we find a product that meets a need, if it suffers from reliability issues and just flat-out doesn’t work well, it suffers from poor product quality.
In the lexicon of software quality assurance, these concepts are described in terms of verification and validation–verification answers the question “are we building the right system?” and validation answers the question “are we building the system right?” This demands that an organization push quality assurance up from the end of the SDLC towards the beginning, so that QA Engineers are involved with the initial design and specifications. Additional eyes on design artifacts at early stages of development help to expose potential problems and guarantee more of the right questions are asked early enough for them to make a difference, rather than afterward when the only question that can be asked is “I wonder what would have happened had we….?”