Newspapers on paper are on the way out. Whether newspaper companies are on the way out too depends. Some of them are going to find the answers. And some are going to fritter away the years quarreling about staff cuts.This prediction isn't original, but I haven't seen any other journalist express it so starkly.
Saturday, September 30, 2006
Friday, September 29, 2006
According to Wikipedia:
A business analyst (BA) is responsible for analyzing the business needs of their clients and stakeholders to help identify business problems and propose solutions.A common activity of business analysts is to document business processes. Business needs typically stem from inefficiencies and problems in these processes. To the extent that your business analysts solely document the processes - as opposed to eliciting and researching them, identifying the inefficiencies and problems within them, and proposing solutions - your BAs have a very tactical role.
There is nothing wrong with such a role, as long as the people performing the more strategic functions are qualified to do so. Be careful about relying on subject matter experts (SMEs). Being experts in a domain doesn't by itself qualify them to analyze business processes and problems.
Thursday, September 28, 2006
It's when you have a only a few customers that you have a great opportunity to go the extra mile to make them happy. Don't blow it.
Stopped by Champion's Sports Bar for lunch today. Hadn't been so figured it would be good to try.
First impression is that it was yet another chain in Austin which isn't surprising since it's in some Mariott derivative hotel by the convention center.
Bartender messed up my order and another guy sitting at the bar. That's ok, it happens and he offered the other guy a free mystery beer.
Later the guy wanted to watch something other than what was playing. There are 3 customers at the bar and 5 tvs. It's Thursday afternoon and not much is going on. The bartender tells him that he's not allowed to change any of the tvs. Customer asks for the manager. Manager doesn't come for 10 minutes. He says that he can't put anything other than sports on (even if it's muted) since they are a "sports bar."
At which point I decide I am not going to come back to a place with overpriced food that won't take care of their customers.
Guess they can join the list with Iron Cactus and a few other places that are too good for their own customers.
Wednesday, September 27, 2006
Tuesday, September 26, 2006
In the 1970s, the Polish government set out to make its furniture industry more competitive in the global economy. To that end, the government rewarded furniture factories based on the total weight of their products manufactured. As a result, the citizens of Poland now have the world's heaviest furnitureWhat you measure and reward is generally what you improve. So Young suggests we, as marketers, concentrate on metrics that are directly relevant to the bottom line (cash flow, revenue). He lays out a procedure for mapping marketing activities to outcomes and metrics.
A pitfall of this approach is that marketers can't control the bottom line. Imagine, for example, all the company's sales reps quit. Revenue will drop no matter what the marketers do. Should they be held accountable?
Monday, September 25, 2006
Sunday, September 24, 2006
Stevenson mostly reports the findings in the book What Sticks, by Rex Briggs and Greg Stuart.
Saturday, September 23, 2006
Each episode, the narrator profiles a U.S. city while at the same time describing a mysterious or brutal crime that occurred in the city. The show is both suspenseful and humorous. Its tongue-in-cheek attitude reminds me of mob shows like The Sopranos.
One episode on Philadelphia focused on the "sausage king", a guy who made and sold sausage but got in trouble with inspectors. So he shot all of them. The narrator said something like, "When the sausage king shot them, he shot them in cold blood - as cold as a frozen kielbasa."
Friday, September 22, 2006
Thursday, September 21, 2006
Wednesday, September 20, 2006
How much is useful for defining requirements for web apps development? Simulation or prototyping seems the efficient approach. Software by iRise and Simunication allows build of real simulations of web apps to identify requirements (the latter even hosts online build) so much of the discussion seems a bit dated for this sector.Asking whether it is useful to define requirements for web app development is equivalent to asking,
Is it useful to understand the problem a web application is supposed to solve?A requirement is a statement of the least stringent conditions that must hold to solve or avoid a prospect problem. As such, it is nothing more than a logical transposition of a problem statement.
Does the fact that a product or system is a web application mean that understanding the problem it solves is "dated" and not useful? Curious, indeed.
Tuesday, September 19, 2006
"the user interface will be available in English, French, and Spanish"
Kevin's point was to illustrate how some requirements are testable but not quantifiable, since "quantifiable" implies numeric measurement. I understand and agree with his point. "English", "French", and "Spanish" are not numbers :-)
However, I wanted to digress a bit and further evaluate his example of a requirement. His example strikes me more as a design decision than a requirement.
Why would a stakeholder want the user interface to be available in any of those languages? What problem does it solve to make the user interface available in those languages? The problem it solves is making sure that the target market is able to use the product. Presumably, the target market includes a substantial number of English-, French-, and Spanish-speaking people.
The real requirement is to make the product usable by these people. Usability requirements typically include profiles of various types of users. Instead of specifying that the user interface must be available in various languages, the requirements should simply include language-speaking characteristics in the user profiles. The product must satisfy the usability requirements for these users.
Monday, September 18, 2006
I heard some new ideas about NFRs [nonfunctional requirements] - One was that the distinguisher is that FRs [functional requirements] are quantifiable and NFRs are not. I'm not sure that I think any requirement is not quantifiable if you try hard enough to make it so.In my opinion, these anecdotes only underscore just how misunderstood requirements are. People at a requirements conference were saying these things? Wow.
A further explained response was that using “testable” as a distinguisher, meant that the requirement can be tested by execution of the system (FR = function or performance) vs something you might test about the environment of the system (NFR = maintainability).
As I've mentioned, a nonfunctional requirement is just as testable and quantifiable as a functional requirement.
Functional requirements state what the system should do. The system either does it or doesn't do it. So sure, functional requirements are testable.
Nonfunctional requirements are simply metrics that we attach to functional requirements. While the system is doing whatever it's supposed to be doing, we can measure things like throughput (performance), how long it takes for a typical user to accomplish her goals (usability), the percentage of time the system is available to deliver any particular functionality (availability), etc. These nonfunctional requirements are by their very nature testable (at least in principle) and quantifiable.
Sunday, September 17, 2006
Saturday, September 16, 2006
When I posted the items on Craig's List, I was bombarded with offers and had trouble keeping track of them. Apparently, Craig's List has taken over and made the forsale newsgroups obsolete.
Friday, September 15, 2006
One way to tell whether the agency gives you good advice is to assess whether they recommend narrowing the scope of your brand. By far the most pervasive problem with brands is that they are not sufficiently focused. Therefore, chances are your agency should be recommending that you narrow your message. The effort should be a renarrowing effort, not a rebranding effort.
Thursday, September 14, 2006
A clear problem statement is, in many cases, just as important as the requirements themselves.I agree completely that clear problem statements are of utmost importance in product management. However, I don't think Joe shares my view that problem statements are requirements, or at least are logical transpositions thereof.
If the problem is
It takes more than five seconds for a user to make a reservation.Then the requirement is
The total amount of time it takes for a user to make a reservation shall not exceed five seconds.Joe goes on to explore how you can further analyze and decompose problem statements:
For example, a company may know that their overall processing time for orders is too long. They may not, however, understand all of the individual problem statements that add up to that company-wide issue. Breaking this problem down into individual subcomponents for analysis and definition requires the exact same skill set used in solution analysis.Again, I agree that problem decomposition is an essential product management activity. Where Joe and I seem to disagree here is over whether "subproblems" serve as the foundation for requirements - or for design.
Typically, customers do not care about "subproblems" except insofar as they contribute to the larger problem they want to solve. "Subproblems" contain assumptions about the way the product or organization currently operates. A new product will often dispense with at least some of these assumptions. Therefore, which "subproblems" you choose to address is a matter of design.
Part of a product manager's role is to find the right place to fit into, or even transform, customers' processes. In this sense, a product manager engages in some of what we might call "business process design". However, the product manager should always strive to select the highest-level problem to solve, to the extent feasible.
Wednesday, September 13, 2006
Now, Apple has the results of a study comparing productivity when using its 30-inch external monitor versus using a smaller 17-inch monitor. Among the major conclusions:
- Computer displays are a widely overlooked productivity factor of the personal computer, and they can contribute significantly to productivity, efficiency, and overall throughput.
- Productivity and efficiency gains documented in these productivity measures are present in not only digital imaging and design applications, but also in office applications as well as in personal productivity of the computing environment.
- A larger display area often results in new productivity strategies that make best use of the display in ways that one cannot easily imagine when working on a smaller display.
Tuesday, September 12, 2006
There are many jobs that a product manager may do, and while most focus the vast majority of their time gathering requirements and selling the products to the sales team, I contend that another equally important role is necessary. This role involves selling the engineering team on the value the new features or changes in the product will have for the customer (and ultimately the success of the group). In other words, for a product to be successful, the engineering team must be motivated to implement the product manager’s feedback. Many projects have failed or been plagued by engineering feature creep because the team did not have confidence in the information stream coming from the product manager(s).A product manager's responsibility is to help the entire product team fully understand and appreciate the needs of the customer. This responsibility underscores the product manager's facilitative role. The most effective product managers facilitate not just customers, but sales, marcom, and developers.
Mike goes on to propose some ways that a product manager can use objective data to persuade developers. While objective data is helpful, I think fundamental facilitation techniques - active listening, the Socratic method, etc. - are what's most important.
Monday, September 11, 2006
Imagine you have a mature software product that is popular in the marketplace but has a key weakness: customers have difficulty using it the first time. A competitor has included a wizard-based user interface to overcome this problem. Wikipedia defines "wizard" as follows:
A wizard is an interactive computer program which acts as an interface to lead a user through a complex task, using step-by-step dialogs.So you have a pretty straightforward solution to the problem, and you can document this solution by simply specifying what the wizard will do. But it's not a product manager's job to do so. This activity is a design activity, not a requirements activity.
A product manager should document the problem being solved, not the solution to that problem. In this case, the problem is that it takes too long for a customer to use the product for the first time. The requirement, accordingly, should be a learnability constraint. That constraint should already be included as a requirement for the existing product; the upgrade merely tightens the constraint (specifies a smaller amount of time to use the product the first time).
Often, a product upgrade does not add new requirements. Rather, it simply tightens existing nonfunctional requirements. If you find your product manager specifying a lot of new requirements for a product upgrade, she probably is shirking her responsibilities.
Sunday, September 10, 2006
The iPod, the digital music player beloved of everyone from Coldplay's Chris Martin to President George Bush, is in danger of losing its sheen. Sales are declining at an unprecedented rate. Industry experts talk of a 'backlash' and of the iPod 'wilting away before our eyes'.Has the iPod turned into a parity product?
Saturday, September 09, 2006
Hand-in-hand with this trend is the tendency of people to commit to actions and then not follow through. I have had acquaintances assure me repeatedly they would attend certain events, only to be no-shows without any prior notice.
These trends may be a result of the fact that people are simply more accessible these days. Or maybe I just have chosen acquaintances that are a lot more flaky. Either way, it frustrates me.
Friday, September 08, 2006
"Vista," in Latvian means "fowl." Yes, that's right. People are awaiting the release of WindowsVia CNET.
Chicken." The word "vista" is also used as a slang term meaning "frumpy," when referring to a dumpy woman, according to a story from Agence France-Presse.
Thursday, September 07, 2006
Wednesday, September 06, 2006
Tuesday, September 05, 2006
To instill messages in the mind of the customer, you must present them credibly. Merely telling the customer that your product is the highest quality or easiest to use, for example, isn't credible. To make your message credible, you can employ symbolic focus.
Using symbolic focus means picking a very specific feature or attribute of your product that is concrete and is undeniably present in your product but in no one else's. By itself, it may be of little or no value to most customers. But it exemplifies or is symbolic of the larger message you are trying to drive home.
When you employ symbolic focus, your claim is credible, because it is unique and not vague. As a bonus, if the feature is remarkable in some way, it will generate word of mouth. When you do communicate the larger message, it will be more credible.
Monday, September 04, 2006
Sunday, September 03, 2006
a. The envelope is plain and merely has the sender's address and your address.I don't know about you, but the plainer the envelope, the less likely I am to consider it junk.
b. The envelope is "busy" and has words such as "Important information. Open immediately!"
Saturday, September 02, 2006
- Don't charge a cover. This suggestion is related to the free food and beverages theory.
- Don't do a charity event. If you think that adding a charity element to the event will enhance the appeal, think again. (The exception, of course, is when the whole purpose of the event is charity.)
- Don't make the guest list private. People are generally what make the event. If you make the guest list private, you're effectively making it so that people don't know if the event will be any good.
- Don't hype. By hyping I mean sending a lot of reminders or including language like "everyone is going to be there!" When you hype an event too much, you're either implying that the event isn't all that appealing on its own merits or that the people you're inviting aren't special.
You can usually recruit a handful of people to help supply food and beverages and let everyone else freeload.
Friday, September 01, 2006
[W]hen you approach an automated teller machine, what is the essential piece of business that you wish to conduct? 'Withdraw money from your bank account' would be a logical answer. The things that you have to do like insert a plastic card, enter a PIN, and so on are to do with the technology that the bank chooses to use. The essense is that you access your account and withdraw money from it.Then ask yourself, for example, why you might design the system to have a PIN. The answer points to another essential problem to solve: unauthorized access to funds. The PIN isn't the requirement; security is.