It isn't all about the code?
This is the coneblog journal and related categorized archives. You can read the blog as written back to front, or browse the categorized archives at right - check out the about categories for guidance on that is where. For a quick overview of the types of content you might run into, check out the Best of coneblog - some of my personal favorites.
I heard Roy Rosin from Intuit speak recently on innovation in the software industry, and I was impressed with his insight.
Roy Rosin is Leader of Innovation Programs in the Small Business Division of Intuit, the software company that provides QuickBooks and TurboTax, among other products.
Roy first talked about the market. The small and medium businesses market (SMB) consists of two segments. The Small Business segment covers the 23 million sole proiprietors and small businesses in the US alone, while the mid market segment covers the approximately six hundred thousand mid market businesses in the US. Intuit has versions of QuickBooks targeted at both segments. Roy described Intuit’s product design goal as “Design for Delight”.
How does Intuit conduct product innovation and design? Here are some tips from Ray:
• Listen and Dig Deep: Listen to the user and understand their concerns. Don’t be content with your initial impression, or even what the customer thinks is the problem that you are solving. Does the customer want a sharper razor, or do they want to shave less often as a result of a closer shave?
• Savor the Unexpected: Prodigy (remember them?) had a commanding lead in users of their on-line community (before the internet). Their model focused on access fees, and on-line information sources, and shopping. Their customers began to ask for e-mail, and e-mail became accepted. Prodigy saw this as an added service, and charged extra for an e-mail account. AOL saw this as an opportunity, and focused their service on e-mail, contacts, and communication. This approach, plus the wildly successful marketing tactic of distributing millions of free diskettes (remember them?) allowed AOL to bury Prodigy in the marketplace, even though Prodigy was the established leader.
• Think Whole Product: Innovation is product focused, but hitting the mark with a success ful product requires and end-to-end solution. Think through marketing, channels, sales mechanics, conversion/setup, integrations with other product classes, input, output and the value you can provide at every step.
• Use Observational Research: Roy defines this as the study of “Real work being done in context”. The best source of product ideas and refinements is watching real users do the task, with all of its challenges and warts. Avoid the Eight Guys in a Room trap. Where you spend your time in a room with flip charts and white boards mapping out how the user should perform the work.
And one from me: Think Niche. SAAS is a whole new model that takes much of the cost out of the product delivery model. What this means to you is that you don’t have to solve all or most of your users problems, to create enough value to support the exorbitant cost of delivering your software or service.
The old successful model was the Enterprise model, where you solved all of the customer’s problems with one comprehensive suite (Think SAP, Oracle, Peoplesoft, or Netsuite), and charged millions.
Costs are low, so product focus can be small and laser focused. You can have a business being just the best e-mail marketing service out there (there are several very good ones). Find one interesting problem to solve, and be the very best at it. Provide for integration. Once you are established, you can “expand your footprint” in the customer’s world.
In the interest of highlighting a technique that we all probably use, I’ll share an effective PM strategy – the “Oh Crap” meeting. An “Oh Crap” meeting can is an opportunity for the project team to identify problems, vent, and sometimes even confess.
In the course of most projects, there comes a time when the project has gotten off track. Sometimes this occurs early, when the scope or design had not closed, and it is obvious to all that the project is adrift.
Highly structured projects seem to work for other crafts, not so much for software. Why is that?
Projects with well-defined, sequential phases are often described as “waterfall model” in the software industry. Projects structured in this way are the standard in construction, for instance. In Construction, you absolutely have to erect the structural steel before you pour the floors. But in software, waterfall projects were found to suffer from several problems:
- It took too long to define every detail of the project in Requirements or Design form. Once you did, there was a whole maintenance cycle around the documentation.
- The design process was often carried out by technicians who didn’t understand the business objectives and organizational barriers, and key insights were missed – until the system went live, when the flaws were all too apparent – reference my eight guys in a room post.
In comparing projects, one aspect I’ve been thinking about is the level of dependencies.
Where I live there are a number of road construction projects going on right now. Seems like this has been the case for several years. When driving around the traffic cones, movable barriers, and temporary roadways around the grading or bridging, I think about project management ( -- doesn’t everyone?).
A Zen Master’s quote got me thinking about Project Management.
In the past, I have been criticized for any number of project management misdeeds. I’m told that I have a tendency to shoot from the hip, modify on the fly, and to Not Work the Plan.