Conducting customer interviews is a great way to validate, or invalidate, your product idea. Interviewing potential customers is almost always a cheaper and faster way to learn what your customers’ needs are, compared to building the product first and then discovering that you built the wrong thing. Even with an existing product, you can discover which new features will be most valuable through customer interviews. Here’s a great video that explains how to do it.
Chris' lastest InfoQ article surveys several other writers' methods for bringing business value to bear on Agile Estimation. Pascal Van Cauwenberghe points out, usefully, that Agile estimation techniques that put the user story first may be putting the cart 10 or 15 degrees askew of the horse: "Pascal proposes that a better starting point is with the question: 'How
do we find the User Stories that deliver the Business Values?'" My favorite, however, is Brandon Carlson’s application of Thin Slicing, a concept he discovered while reading Malcolm Gladwell’s Blink. Carlson writes:
The book cites an example of how doctors at Cook County Hospital
improved patient care and throughput using the technique. I thought to
myself, if doctors at Cook County Hospital can use a small subset of
relevant attributes to effectively prioritize patients in life or death
situations such as an ER, it could certainly be applied to even more
important decisions such as the prioritization of features, right?
Carlson describes how he turned a "sick" 90 minute weekly meeting into a hummingly efficient 30 minute process that got better results and left all the stakeholders more satisfied. The idea of looking to the Emergency Room for for triage practices that can help other businesses keep an eye on the vital signs is a brilliant example of the value one adds by reading across other disciplines.
Looking for a good starting place for the agenda for your next meeting? Here is an Excel file that you can use. There is more here than you will likely need for any given meeting, so just remove the extras that you don’t use.
At the top you will find:
The most important thing to know about your meeting: what do you hope to achieve?
Location, Date, and Start Time
OK, pretty obvious.
This gets calculated auto-magically for you.
Who is calling this meeting?
If this meeting will have a facilitator (a very good idea), who are they?
Scribe and Time Keeper
Other roles that may be helpful
The bottom of the agenda is where you put your agenda items. There are six columns:
Well, what is the agenda item anyway? Give it a short description.
What process will the group use for this item? Possibilities include: brainstorming, discussion, voting, or perhaps group wisdom without groupthink.
Why are you discussing this anyway?
Who will own this agenda item?
This column is useful when creating the agenda, as it lets you figure out how much time you will need.
This value calculates automatically based on the start time of the meeting and the length of all of the agenda items before this agenda item. This is really useful to have during the meeting, so that you can tell if you are running on time.
Download it now!
Leave a comment to let me know if you find it useful, or to share any suggestions or tips.
Tonight I will be presenting my SWOT analysis workshop to the East Bay Innovation Group’s Software Development Best Practices SIG. The event is free and they will feed you!
Tonight at 5:30 PM
Communications Technology Cluster
300 Frank H. Ogawa Plaza, Suite 210
Oakland, CA 94612
I occasionally still get calls to do software development. Recently, a potential client indicated that they would like a Windows shell extension created in C#. I’ve never built a shell extension, nor done any C#. Before meeting with the client, I decided I should take an hour or two to see how hard it would be for an old-school C++ and COM guy like me to get up to speed.
I downloaded the ‘Express’ version of C# and started playing with it. Pretty quickly, I had a command line app that worked like Eliza, but got the response text from Google searches. Fun!
Next I searched MSDN for information on using C# to create shell extensions. I found this article, which starts out like this:
This article illustrates the process of creating custom shell namespace extensions using C# and the .NET Framework. The author dispels some myths about the difficulty of writing such extensions, and shows that it is easier than it was before .NET.
Until you get to here:
Because shell extensions are loaded into arbitrary processes and because managed code built against one version of the runtime may not run in a process running an earlier version of the runtime, Microsoft recommends against writing managed shell extensions and does not consider them a supported scenario.
Reading up a bit more it seems that COM, not .NET is really the right technology to use. It’s nice to see that my C++ and COM skills aren’t obsolete yet.
I found this interesting article on the Harvard Business School Working Knowledge site. It examines 13 pay-for-performance programs that various groups in HP tried and dropped. There are lessons to be learned from these experiences.
What gets incented gets done, at the expense of the rest of the stuff. Think about the side effects of any incentive program. Giving extra pay for outstanding individual accomplishments is not going to encourage teamwork, for example.
Manage expectations; better to start with goals that are too high than too low. If management finds that fewer people than expected are able to perform up to the incented level, it is a simple matter to adjust the level down a bit next cycle. If, however, more people than expected make it the first cycle, they are likely to cry ‘Foul!’ when management adjusts the levels up next time.
Creativity and learning are tough to incent with a pay-for-performance program. Such programs tend to reward ‘success’ and results, not experimentation, trial and error.
I agree that these programs can be hard to get right, and are costly when they are done wrong. In management, as in engineering, it is often the hardest things that are most valuable. Pay-for-performance is a tool. It is management’s job to decide if it is the right tool.
My friend Peter started working at EvilEmpireSoft on the same Monday that I started at Geekaplex. That Friday, over beers, he told me that he had spent most of his first week waiting for his laptop to show up. When it finally showed up, it had an outdated version of the development environment installed which couldn’t compile the code he was supposed to be working on. On top of that, Outlook was misconfigured and wouldn’t even think about connecting to the mail server. He spent an afternoon figuring out the configuration only to discover that his email account hadn’t been activated yet! “It’s as if they were surprised when I showed up for work on Monday. Maybe they forgot that they hired me? I spent the first morning waiting in HR until someone was available to give me paperwork to fill out. After that,” he went on, “I spent the afternoon wandering around looking for an empty cube to claim.”
I felt bad for Peter, and I was almost embarrassed at how different my first week had gone. My office was just down the hall from my boss’s. There was no mistaking that it was mine, as my name was on the plaque next to the door. Inside, I found a shinny new ThinkPad with a docking station and a pair of flat-screen monitors. The drawers in the desk were filled with new pens, pencils, paper, a stapler, and even a box of freshly printed business cards. My boss sat down with me and walked me through my first week, pointing out the various meetings and training sessions that were already on my calendar. There was even a welcome email from the president of the company waiting in my in-box.
“Wow!” Said Peter, “You’re like a VIP over there! I feel like most folks don’t know I exist, and if they do, they are just hoping that I won’t bother them. It really sucks. EvilEmpireSoft seemed so cool and together when I interviewed, but now I’m wondering how they get anything done. They aren’t the elite, well-oiled organization that I imagined them to be. I feel like I made a big mistake accepting their offer.”
What a big difference attention to detail and a little preparation made. By simply taking the time to provision my office, my boss sent me a strong positive message about the company, and how much they valued me. Additionally, by making sure that I had all the tools I needed to be productive, they let me know that they expected me to be productive. I felt like Geekaplex had it together, and that they would expect me to have it together as well. I felt welcomed and challenged.
LinkedIn has a cool feature that let’s you ask a question of your whole network. This morning, someone in my network asked this question:
Tools for visualising interactive prototypes? What do you prefer?
Powerpoint, ConceptDraw, Omnigraffle, Flash, Ruby on Rails?
We are reviewing the tools we are using to help visualise interactive storyboards and concepts for our clients. What are other people using? How important is it that the tool supports experimenting with real data and conditional branching in order to explore with the development team the consequences of their design decisions?
Consider Paper Prototyping.
It is low cost, easy to do, and will quickly teach you how a real user will react to the system. With a paper prototype, a human acts as the computer, so your prototype can support some very sophisticated logic without the need to create code. Modifications are trivial, encouraging experimentation, discovery and improvement. I was skeptical at first, but after using it a few times I have become impressed with the power of this tool.
I wasn’t liking my business cards.
So Hillary and I spent a couple of hours on Overnighttprints.com today and came up with something that I like better.
What do you think?