Austin’s 3rd UnConference for product managers and product marketing managers is coming up on August 15t.  If you’re in Austin or can come to Austin, you should definitely plan on participating – it’s free, and a great opportunity to network, share, and learn.

ProductCamp – What Is It?

The first ProductCamp was started in the San Francisco Bay Area by Rich Mironov and the folks at Enthiosys in March 2008.  The largest one so far had 375 participants in the Bay Area, and the most recent one was last weekend in New York City.  As I type this, the ProductCamp Austin has 217 signups and 26 proposed sessions – less than a week after the announcement.

ProductCamp is a free, collaborative, unconference about product marketing and management.  ProductCamp is a bunch of smart, passionate people coming together to discuss, debate, and collaborate on the issues they face every day.  Everyone brings different experiences and leveraging that collective knowledge is what makes ProductCamp special – and something you can’t get anywhere else.

There are ProductCamps happening in more locations every day: San Francisco Bay, Austin, Toronto, New York City, Research Triange Park, Atlanta, Seattle, Boston, and maybe some more that I’m missing.  Someone created a web page that lists upcoming product camps (although it doesn’t provide any other information yet [if you're the owner of that site, comment below and let folks know how we can help connect the other city-specific sites to yours]).  There’s also a list of “all” past product camps on the barcamp.org wiki.  I know it is currently missing some of the events, but hopefully will emerge as the canonical list.  There’s also a newly created facebook fan page for all of the ProductCamps. It has a link to the Toronto ProductCamp fan page, and to the Austin ProductCamp fan page and hopefully soon, to any others that have been created.

If you know of a past ProductCamp that is missing, please update that wiki page (or contact me and I will update it).

Check out Paul Young’s recent article about Product Camp Austin and what to expect (if you haven’t attended one in the past).  Paul also gave a webinar yesterday about ProductCamp – with an introduction for new-to-ProductCamp people, and guidance for how to start a ProductCamp in your area.  You can download his slides and listen to the 40-minute audio track at the link.  Thanks to Ryma and Val Workman for hosting the webinar!

ProductCamp – How Does It Work?

Volunteers in each city put a lot of time into organizing the events, finding venues, soliciting donations to cover costs, encouraging people to participate, creating awareness of the events, setting up, tearing down, etc.  The event is free for people who attend – all that is asked is that people who attend help out.  Ideally, that means hosting a session (a presentation, roundtable, panel, workshop, etc) or participating in one; or it could mean helping out before, during, or after the session.

ProductCamp – What’s Going On?

There isn’t quite critical mass for any one site that aggregates all of the ProductCamp information.  This is an emergent phenomenon – and if you’re reading this after Jul 23rd 2009, the links above may not be the best ones.  For now, Twitter has emerged as the best way to see what’s going on with product camps.  The way to keep up is to search for hash-tags that the different product camps are using, find people who are tweeting about the product camps, and do some discovery leg-work.  Try searching Twitter for any of the following: productcamp, #pcamp, #pca09, #pct2, #pcampnyc, and certainly some others [add to the comments below].

ProductCamp Austin – How’s It Shaping Up?

As of this morning, for ProductCamp Austin Summer 2009 (main wiki page, facebook page, twitter search term, registration page, session-proposal page), we have 219 people registered, and 26 sessions proposed.  One thing we’re doing this year is capturing a demand signal from people as they register – specifically, what topic areas would they be interested in seeing presentations about.

We asked (are asking) people to select the three topic areas of most interest to them, from the list:

• Marketing
• Agile
• Requirements
• Product Strategy
• Career
• Other

Here’s a snapshot of the data at the moment:

Larger (and current) images of both graphs are maintained on the session-proposal page of the ProductCamp Austin Summer 2009 wiki.  This information is intended to inform the people who are proposing sessions – it is a demand signal.  There are no quotas by topic area, no requirement that sessions be in a particular area, etc.  Just information to help presenters pick a topic area (when they are undecided).

ProductCamp Austin – Finding Presenters

We’re driving participation “top down” because we’re creatures of habit.  However, what I personally believe will be more effective is for you to get people to host sessions at ProductCamp Austin.

• Do you know someone who is a great presenter with something to say about product management or product marketing?  Beg them to present.
• Do you work with people who have great insights about a particular area?  Bully them into participating in a panel (and volunteer to run the panel).
• Have you met someone who is facing a particular challenge and is looking for answers?  Convince them to organize a roundtable on the topic (and convince people with experiences to attend).
• Have you learned from someone who is a great teacher?  Cajole them into running a 50 minute workshop where people can learn something valuable and tangible.

Or of course, when you fit into any of these categories, volunter :).  And when asked by someone else, be flattered.  And say yes!

Paul Young (ptyoung on Twitter, Author of Product Beautiful) is the driving force behind organizing Austin’s product camps – thanks Paul!

Jun 14th was the first productcamp in Austin (and the second one anywhere).  It was a great event, and here’s the presentation that I did on how to define the strategic problems that drive our products.

Defining Problems

Here’s the presentation I gave at ProductCampAustin 1, posted on slideshare.  Just click on the forward/back arrows in the center of the bottom of the image, and it will cycle through the presentation – you don’t even have to leave Tyner Blain.

| View | Upload your own

Following Along

In keeping with the “don’t put a lot of words on your slides” tradition, the presentation is probably all but impossible to follow without some notes.  So here are some notes, organized by slide.  The presentation builds on concepts we’ve talked about here over the years, and in the notes below, I’ll link to some of those previous articles to provide more depth (instead of typing out everything I said).

• Slide 1.  There are two key elements to achieving software product success.  Build the right stuff, and build it right.  This presentation is about building the right stuff.
• Slide 2.  Specifically, when we start a project, it is to achieve some business objective.  The challenge is to find the right level of abstraction for that objective.  “Increase shareholder value” is too nebulous, and “Replace a legacy system” is too lacking in context.  Today we will apply a very powerful, but simple technique to help define the business objectives at the right level of detail to be actionable, while providing the right context to validate that we’re doing the right thing. My goal is for everyone to leave here with a new skill that they can immediately apply.
• Slide 3.  Everyone has a different perspective on a software project, and from those vantage points, perceives different elements of the project as the “why, what, and how” of the project.
• Slide 4.  Keeping in mind that people have different perspectives, let’s also look at a modified version of Karl Wiegers’ structured approach to requirements definition.
• Slide 5.  Introducing the Ishikawa diagram.
• Slide 6.  Set up the “deflated tires” problem from the article linked in (slide 5).
• Slide 7.  Showed the discovery process and representation of “real problems” closing out the theme from slides 5 and 6.
• Slide 8.  A real-world project I joined mid-stream for a client.  The project was a “collection of stuff” and no two people would give the same answer for “why are we doing it” and many people unashamedly admitted that they had no idea why.  No idea why!
• Slide 9.  Turns out, here’s what a view of the value for that program really looked like.  The team went from chaos to context.  Suddenly, scope discussions and prioritization decisions had a framework for validation.  There was also an organized way to begin completeness analysis.  Much easier to say “we’re getting this value” than to say “we’re doing these things – did we miss anything?”
• Slide 10.  I facilitated the folks in the room creating an Ishikawa from scratch.  We started with what we thought was the problem statement (provided by John Milburn from the back of the room) – “Traffic in Austin on Fridays is too bad.”  We ended with “John has work-life balance problems”, one of which comes from missing dinner with his wife, which can happen because of a combination of bad traffic and bad planning by John.  We also explored several solution-paths, including increasing the capacity of the roads and of the vehicles.  The ideas clicked for several people in the room.
• Slide 11.  Another real-world example, this one used in planning of a product roadmap for an 18-24 month view of the problems the team was signing up to solve.
• Slide 12.  Special thanks to the sponsors that made our inaugural ProductCampAustin a success!  My prediction for the next one (fall/winter 2008): 250 attendees.  So if you’re the sponsoring type, start planning on how you can help out.

Thanks again to everyone who attended, and special thanks to Tal Boyd of Seilevel, who video taped my whole presentation.  I just haven’t figured out how to split the 400+MB m4v file into something I can upload onto youtube.

No, not that kind of camp.

Product Camp

Austin is having our first product camp – an unconference. The agile development world has been running very successful bar-camps for a while now, a way to have a conference without having a conference. The product managers in silicon valley successfully held their own product camp (called p-camp) on March 15th of this year. Not to be outdone, Austin is hosting our very own productcamp!

Paul Young, of Product Beautiful, is the instigator of this wonderful madness. With the help of Pragmatic Marketing’s John Milburn, Cauvin Inc.’s Roger Cauvin, Rob Grady, he is making things happen!

From Paul’s announcement:

I’m happy to announce that we are going to be running Austin’s first ProductCamp. Much like BarCamp, ProductCamp is a collaborative, user run event, except where BarCamp is often focused around topics interesting to Developers, ProductCamp will be focused Product Management and Marketing topics.

Announcing ProductCamp Austin

Here are the event details from the official ProductCamp wiki:

When

Saturday June 14th, 2008, 8:00 AM – 6:00 PM

Where

St. Edward’s University Professional Education Center (PEC)
9420 Research Blvd
Echelon III Building
Austin, Texas 78759
(512) 346-8110

ProductCamp Austin wiki

Roger put the call to arms best:

There are two ways you can get more info or get involved:

1. Go to the wiki (collaborative web site) and sign up as a participant.
2. Join the planning group on Google.

Everyone interested in product management, marketing, and developments processes is invited, but we encourage attendees to participate (volunteer for setup/teardown, speak, lead a roundtable, set up wifi, etc.) in some fashion.

ProductCampAustin

So sign up, participate in the planning, make travel plans if you’re unlucky and live somewhere other than Austin, and COME TO PRODUCTCAMP.  Make sure and check out the ProductCamp Austin wiki to see (or add) topics of interest – or to offer to present or participate!

[psst: hey business analysts - you do a lot of this stuff too.  you don't have to print up business cards that say "Product Manager" in order to deal with prioritization, requirements, politics, off-shoring, competitive analysis, market research, time management, roi, etc.  so don't feel excluded - participate!]

Netlife Research (company website in Norwegian) has done it again. Their 2008 Bad Usability Calendar is here and it is great. So great that it is hard to pick a favorite. Download it here. 2007 has more great examples.

[Note: This is a short post- just got back from the Velvet Revolver concert at Stubb's. Living in Austin rocks!]

Welcome Dr. Franke’s students in Analysis, Modeling and Design MCIS6310! Thanks again for inviting me to present to your class on requirements gathering and requirements management.

The presentation is available for download. You can get both the slides and the notes pages. The notes pages include additional content and links to articles for further reading on the individual topics.

For the rest of our readers – the presentation for the St. Edward’s class is primarily written for people with little exposure to formal requirements management processes. It does not go into the depth of most of our articles, and instead hopes to present a broad overview of what we do when managing and developing requirements.  The presentation is 34 pages (about 90 minutes speaking time)
If you’ve been reading Tyner Blain for the last few months, there is little new material. If you’re new to Tyner Blain, the presentation is worth a quick read. Although we didn’t record the presentation, the notes-pages will provide some additional context to the slides.

Requirements management software will not solve our requirements problems.

Jerry Aubin of Seilevel made this great point in his presentation this evening at the IEEE Computer Society, Austin / A-SPIN event. This was a great event, focusing on how to take requirements management “to the next level” – not just being good at it, but being great at it. Seilevel’s speakers (Jerry and Joe Shideler) demonstrated that they have great insights into the art and science of requirements management – and presented some cutting edge ideas that extend the “known good ideas” in some interesting directions. Definitely a company to keep our eyes on and learn from. Their blog, requirements defined, is linked in our blog roll – check it out.

The Norm Abram analogy

Jerry used what he coins as the “Norm Abram analogy”. Norm Abram is a great carpenter, and he does a weekly television show here in the US. He has an amazing workshop, with every tool imaginable for cutting, shaping, sanding or finishing wood. And Norm uses those tools to create beautiful products.

If you had those tools, Jerry asked us, would you be able to suddenly create products as beautiful as Norm does?

No.

Norm became a great carpenter and he became proficient with tools that help him do his work faster. The tools didn’t make him better, they just make it easier for him to do the work.

Would having typewriters make us write better, or just faster?

Applied to requirements management

The same holds true about requirements management software. Having access to software won’t make us better at managing requirements. The software will help someone who already knows how to manage requirements be more efficient.

The folks at Seilevel have seen the introduction of RM software (requirements management software) actually be counter-productive for teams who are new to managing requirements. We agree – we think it’s like getting an expensive car so that we can teach someone how to drive. The learning process has to come first.

Jerry showed statistics from the Standish Group’s 2004 CHAOS report. We’ve talked about that report earlier. That report shows that 71% of software projects fail. The issue isn’t the speed or cost of writing requirements, the issue is writing bad requirements.

For those 71% – the problem isn’t the tool, it’s the training. For the other 29%, there are absolutely solutions to help us do our jobs faster.

What should we do?

There are two ways to get better requirements. Buying RM software is neither one of those.

1. Get help with your requirements. Companies like Seilevel and Tyner Blain have already invested in learning how to do requirements right. Let them or someone else help you manage requirements, or let them do it for you.
2. Learn how to manage your requirements. Get training, read, study, practice, fail, improve, and succeed. As individuals, find mentors. As companies – get outside experts to come in and audit your projects.

When should we buy RM software?

When we’re already good at writing and managing requirements, and we’re looking for a cost reduction. Introducing a tool of this complexity to a team that isn’t accustomed to the process will actually hinder the process.

Requirements versus design – which is what, when and why?

A classic debate. It comes up often. Unfortunately, it’s a source of confusion that causes many teams to shy away from staffing, creating, or managing any formal requirements processes. There’s a discussion on Seilevel’s forum where this has been brought up again, and it’s shaping up to be a fine grudge match here in Austin. Thanks to Cauvin for calling it to our attention. We can’t let the other folks have all the fun, so we’ll chime in too.

We’ve described the software development process before as being like an onion – having multiple layers of abstraction within which you describe the problem and solution. In this post we will translate that perspective into “what is a requirement” and “what is design”.

The layers of abstraction

1. Market requirements. The problems or opportunities that express potential ROI opportunities. These can be captured in an MRD.
2. Product requirements. In a process that uses structured requirements, these are the functional requirements, user requirements and business requirements. Design constraints are also requirements (non-functional requirements). Product requirements can be captured in an FRS, SRS, or PRD.
3. Solution design. The architectural description of the implementation, UI and test suite. Design decisions define much of the reality for developers – good design decisions make implementation and maintenance easy. Bad design decisions can make for disaster.
   
4. Implementation. The actual code that is written and running. The user interface that is presented. The tests that are included in a regression suite. We do what we’re asked, in the way that we’re asked.

The point of contention

The debate is over the classification of product requirements. In this post we’ll talk about the red team and the blue team, much like the foosball players in the image above. We’ll also use one of the examples presented in the forum as the anecdote for describing our perspective. I want to avoid putting words in other people’s mouths, so I will hilight my interpretations as being just that. And as interpretations, they may very well be wrong.

My interpretation is that the blue team believes that market requirements are the requirements, and any further specificity should be classified as design (also this). My interpretation is that the red team agrees with what we’ll write in the rest of this post.

A red team quote:

My philosophy on this is simple. If the business or the business users care about it, it is a requirement.

That being said, the business often times cares or wants things that they shouldn’t care about or want, so they do have to be careful not to demand things that truly arent requirements.

An unambiguous description of requirements and design

There is a middle ground between market requirements and design. There is a step in the software development process that happens between “defining the problem” and “designing the solution.”

When talking about market requirements, we describe the problems and opportunities that define the space. A great place to document our insight into the market is in a market requirements document, or MRD. In this hypothetical example, our mythical company is losing customers because they have to wait too long when they are on the phone to get support.

There is an ideation step, where we perform an analysis – as engineers, we would call this a root cause analysis, where we identify why the customers make software decisions based on support-call length, why the call lengths are long, etc. After we identify the root causes, we determine which ones are properly addressed with software, versus process, project, expectation setting or any other solution.

Our mythical company has decided that there will be a software component to the solution, and it will have the goal of reducing support call times.

The instant we decide that this problem is going to be solved with software, it becomes a software product requirement. And a great place to record that information is in a product requirements document, or PRD. We talk more about this in our post, From MRD to PRD – the key to defining a spec. And this is the source of our disagreement with the red team – we believe that these are both requirements, they are distinct, and they should coexist – and still both be labeled as requirements.

At Tyner Blain, we strongly support the use of structured requirements as a means of capturing, managing, and communicating our software product requirements. We start with the GOAL of reducing the average support call time. We define the use cases that capture the support-call process (or story, or scenario – if that’s your term du jour). We articulate the functional requirements (sales rep can find the customer records for the customer on the phone). And we define the design constraints, or non-functional requirements.

This is where we think we agree with the blue team as long as we add the following clarifications. Design constraints are requirements. When our client expresses the need to conform to a corporate look and feel – that’s a constraint. When we describe support for color-blind users – it’s also a constraint (although it is an ambiguous requirement without supporting material or cross-domain experts on the team). Any time we define performance characteristics (search must happen in five seconds), it is a constraint.

In all these cases, we require the software developers to design a solution within the bounds of our constraints. Constraints are requirements.

The implementation team will design (and later develop and test) a solution based upon the requirements. The requirements include constraints on how the implementors are allowed to design and implement.

Where we disagree with the red team

While generally agreeing with the red team (that requirements do exist between markets and designs), there is one statement where we do disagree.

Red team:

If I specify that the support rep must be able to search by last name, partial names, customer ids, address, phone number etc. Is that requirements or design?

Lets say you can agree that the above are requirements

[...]

Are all of those things design? I think it depends on the capabilities of your teams.

We disagree – we believe that these implementation details (by what fields a user should be able to search – and, in fact, specifying that search is the implementation approach) are not part of requirements – they are part of design.

I understand how easy it is to let project realities affect the classification of some design elements as product requirements. I’ve personally made the mistake of taking that perspective to extremes in the past.

Defining details like this (what, exactly, does the software do) are design decisions. Irrespective of the capabilities of the teams, these are design steps. It may be, for a given team, that the product or requirements manager has to help a particular software designer to make good decisions. But that doesn’t make those suggestions into requirements – it just means that the RM is helping with design. And those details would belong in a design document. Yes it’s more convenient for a product manager to put those details into the PRD, but they don’t belong there.

Summary

In conclusion – there is a natural flow from market opportunities to product requirements to design decisions in the state of all value-driven software development projects. These three concepts are distinct. They should be documented distinctly. We suggest using an MRD, a PRD, and a design document. As a simple checklist, think of each idea in this way:

• Am I describing an opportunity and it’s relative value? MRD
• Am I defining a particular opportunity that we’ve agreed to solve with software? PRD
• Am I describing the implementation of the solution? Design Document

Please join in on the discussion – if not here, then at the forum or on Cauvin’s blog.

We received a comment from Tom Humbarger at iRise on an earlier post, which led us to take a look at their site.

iRise provides a tool for rapid prototyping of web-based applications, and there’s an overview of the products available. They have iRise Studio which allows people to create interactive prototypes of web-based applications, and iRise Reader that allows people to interact with their prototypes.

This is a good news, bad news, good news (at the end) situation.

The good news – they have an innovative idea – use prototypes to communicate requirements.

The bad news – Our initial excitement about their product quickly turned to skepticism while reading their copy…

Who are the target users?

” iRise Studio is a powerful, easy-to- use application definition solution used by business experts to quickly assemble functionally rich simulations of Web-based applications in a matter of hours.“

We are firm believers in the power of prototypes – especially when they can present a compelling vision for an application. The idea that a business expert can create a good one seems a little far fetched.

They’re going to do what?

“Business people can quickly lay out the page flow of simulations and create high fidelity pages that precisely mimic not only the look and feel of the final application, but the business logic and data interactions as well.“

OK, page flow of a mockup, maybe – but business people will not precisely mimic the look and feel of the final application. Even if they could – it would be a bad idea. We’ve talked about the imperative of not specifying implementation details as part of the requirements process. Specifying implementation details is one of our top ten use case mistakes.

The idea of doing the data modeling and business process simulation is cool. Lombardi Software, another Austin company does this stuff – but for enterprise clients. Some of the best people I’ve worked with are at Lombardi, I respect their opinions, and know that they are big fans of being able to do process modeling – and have it drive applications in the real world. If iRise has a comparable interface for modeling, it could be a great tool for rapid prototyping.

Why would they do that?

“The interactive simulations can become visual contracts between business and IT, serving as stable blueprints for what to build.”

OK – now I’m getting concerned. Why is it a good idea to have non-experts specify the branding, layout, interaction design, and usability of a web-based application? Assuming that an expert business process modeler is at the helm, we can expect that high-level workflow is well designed. But the user experience? Show me a business expert who’s competent at designing interfaces and I’ll show you a switch-hitter currently occupying the chair of a business expert.

But we need a good prototyping tool!

The screenshots showing how the application is used to build prototypes look very cool. This application looks like a good product, but their marketing copy sure is targeted at doing the wrong thing. Check out the bits about modeling of scenarios too.
What about the testimonials? Maybe we’re missing something.

Here are some excerpts from the testimonials (note: we’re starting to get excited about the product again)

• “…allow us to rapidly and iteratively validate the client’s needs early in the process ensuring we have the right requirements from the start“
• “to visually validate requirements and “test market” applications prior to investing time and money in development“
• “can engage their business stakeholders early in the process to visually identify missing system requirements, eliminate unnecessary functionality and discuss important process and policy issues“

Yes, yes, and yes!

This is exactly how a prototype should be used.

What should iRise do?

1. Change the way they propose that their clients use iRise. Business analysts, while ideally suited to identify, prioritize and validate requirements, are in no way suited to the designing of software solutions. User experience experts are. A picture is worth a thousand words, and an interactive prototype is worth a thousand pictures. Why risk misleading or dissatisfying the stakeholders with a bad prototype? Why prevent your development team from being able to apply their skills to design a solution? If you’re outsourcing to a development group with limited capabilities, this mindset might seem rational. The answer is to bring design resources in house, not ask non-designers to design.
2. Find small consulting companies with a lot of passion for product success and a big megaphone (hint hint), give them a free copy of the software, in exchange for an honest assessment of how well it works and suggestions on how to incorporate it into effective software development processes.

Lauren Arbittier Davis recently started Alkali Marketing, a boutique marketing outsourcing company here in Austin.  I’ve personally worked with Lauren over much of the past decade, and couldn’t be more excited about her company!  When Tyner Blain is ready to build awareness (beyond our current viral approach), Alkali is who we’ll call.  In addition to a personal reccommendation of Lauren for anything you need, I also know some of her clients, have seen the work Lauren and Alkali have done for them, and know how pleased they are with it.

Check out Alkali Marketing’s site, read their reviews, see what they can do, and schedule a meeting.
Contact Alkali Marketing here.  Seriously.

Scott

Jerry Aubin and Joe Shideler of Seilevel will be giving their presentation, Beyond the System Shall – A Journey from Good to Great Requirements. Although this meeting is sponsored by the Austin chapter of IEEE, it is open to the public.

[Update: The meeting is from 6:30-9:00pm on Wednesday 15 February 2006]

If you were paying attention last month, this is the presentation that was delayed when we had our “ice storm” in December. The presentation has been rescheduled, so update your calendar.

From the summary:

“Today, only a small percent of IT projects succeed while the rest significantly under perform or fail outright. Seilevel will begin the presentation by delving into the statistics behind this statement and then move on to discuss how poor software requirements are a primary reason. The presenters will explore the root causes behind the problem and then provide suggestions as to how companies can improve the situation. […]”

I’ve had the pleasure of working with a few Seilevel folks in the past, and they are top-shelf. I’m looking forward to the presentation – you should make it if you can.

Update: Just realized that the link I included doesn’t have directions – check out the IEEE Austin calendar for directions to the event.