Luke Hohmann’s Blog

OOP 2007 Conference Feedback - I gave a tutorial and a keynote at the SIGS-DATACOMM OOP Conference in January. I was really honored to be asked to speak at this conference, as it was my first ever invitation to speak in Europe. The trip was a bit challenging because of the terrible weather, but the German people were so warm and inviting that I felt right at home. Perhaps my favorite story was that on Wed Jan 24th I needed to take the train from Munich to Heidelberg so that I could teach some Innovation Games(R) classes to staff members and friends of the SAP Design Services Team. Unfortunately, the original train was cancelled. I was lucky to find myself befriended by a German woman (from Brazil, no less!) who was also traveling to Heidelberg. Seven hours and three trains later — I was in Heidelberg.

Another great memory of the OOP conference was that I was invited by the conference organizers to attend a special reception dinner on Monday evening Jan 22nd. At the dinner we had a lively discussion about the pros/cons of changing the name of the conference. Like so many other conferences, the OOP conference has evolved substantially over the years. Yes, objects are still important, but so are many other facets of software development, all of which are covered at the OOP conference.

Should the OOP conference change its name? This is a tough branding question. Delegates from prior years know that the conference covers many topics. The concern, though, centers around new delegates: Will they be put off by a conference with “OOP” in the title if they’re looking for something about agile or product management? In the end, I told the conference organizers that I think they had already made up their mind to change the name of the conference and that we were really discussing “when” they should change the name and not “if” they should change the name. They smiled when I said this. I then told them that I agreed with their decision, and that in this case changing the name seemed like a sensible thing to do.

Here is my conference feedback, received today from Wolfgang Reuter, the very helpful and thoroughly organized Conference Organizer. Click here for the Excel feedback form.

——————————–

Luke,we would like to thank you on behalf of SIGS-DATACOM for your participation at OOP 2007 in Munich.

The initial feedback we received from our delegates was very positive.

Enclosed you will find the evaluated feedback forms of your session.

Many thanks again from the whole SIGS-DATACOM team

Wolfgang

——————————————————

Wolfgang Reuter

Konferenzmanager

Conference Manager

Tel. +49 (0)2241/2341-211

Fax: +49 (0)2241/2341-199

wolfgang.reuter@sigs-datacom.de

www.sigs-datacom.de

Aktuelle Veranstaltungen / Upcoming EventsSIGS-DATACOM GmbH - Geschäftsführer: Günter Fuhrmeister Sitz des Unternehmens: Lindlaustr. 2c, 53842 Troisdorf

Registergericht: Amtsgericht Siegburg, HRB 6552

I was visiting a client of Enthiosys to discuss Agile Software Development practices and during the meeting my client mentioned that her company had recently created a New Product Development / Ideation group.  I looked at the wall and noticed an ideation process map and asked if that map was how this group intended to work. She replied yes, that that process map was the current thinking from this group. She detailed the process, which showed several sources of input into the New Product Development group. Among the sources listed included:

• Corporate strategy
• Corporate capabilities
• Competitive assessment
• Analyst research
• New technology
• Core competencies

There were a few more, but I honestly can’t remember what they were because what was missing just hit me like a 2×4 in the chest. Customer. The actual customers of this client were never listed on this chart. Not once. Not in qualitative research. Not in quantitative research. Simply not listed.

When I asked my client about this, she replied something like “Well, this may not be the final version of their process. I think they are planning on talking to customers, but I’m not sure. Customer support is listed as an input into the diagram — that should help, right?”

I told her that yes, soliciting input for New Product Concepts from internal groups such as sales, professional services, and customer support was helpful, but I also told her that I thought it was an egregious mistake to create a New Product Development / Ideation group that doesn’t talk directly with customers.

In the hopes of stating what should be blatlantly obvious, the foundation of innovation is understanding your customers. This includes talking with them.

The maturity of your target market is one of the strongest influences on the selection and management of a given business model. In the early phases of a given market, business models should be chosen so that they can be quickly and easily understood, primarily because you may not be certain of the best way to structure them. You may find that your customers prefer an annual license to a subscription, or that they expect discounts if they purchase in bulk. Moreover, despite the best intentions of the business plan, innovators and early adopters may expect and/or demand special terms.

As the market matures, chances are good that your business model will become increasingly complex in order to serve the idiosyncratic needs of different market segments. I helped one client whose growth had stalled attack a new market segment with the same underlying system simply by defining a new business model. The original one consisted of an annual license. The new one was pay per use. The easy part was modifying the underlying architecture so that both models could be supported. The hard part was creating the appropriate price points so that a given customer could choose the best model without harming the relationships with current customers. This is not always the case, however, and it is more typical that changes to the business model can cause significant changes to your underlying architecture. These changes are often so large that they consume an entire release cycle (and sometimes two) to fully implement.

The enforcement of business models also matches the maturity of the target market. In early market stages, enforcement tends to be lax. As the market matures, or in cases where you suspect piracy, the enforcement tightens up. My experience is that product managers and software architects take enforcement far too lightly. You’ve worked hard to create your system, and software piracy is a serious problem. Create a business model that identifies the real value provided to your customers, price it competitively, and enforce it accordingly. Just remember that onerous enforcement will lead to dissatisfaction among honest customers, so be careful.

Choosing a business model is one of the most challenging tasks faced by the product manager, as it incorporates a plethora of factors, such as the business and licensing models offered by competitors (which may constrain you to existing market expectations) and corporate and/or environmental factors beyond your control (such as when another division does poorly and you need to find a way to increase short-term revenue). To help you through the potential morass of choosing a business model, consider these questions.

• Who is the target market? What do they value? A crisp description of the target market and what it values is the first step in creating an appropriate business licensing model. If you’re not certain of  what it values, consider how it wants to use what you’re offering. Once you’ve determined your market values, show how your solution provides it.
• What are your objectives relative to this target market? In an emerging market you may wish to capture market share, so create simpler models. In a mature market you may wish to protect market share, so create more complex models to provide flexibility.
• What is your type of value exchange? In other words, what is basic mechanism that tracks and/or causes “money” to change hands?
• What rights do you wish to convey? Begin by asking your legal department for a “standard” contract, as it will contain a variety of nonnegotiable rights and restrictions. Many of these you can ignore. Focus on the business terms that motivate sales of your software.
• What is the affect of this business model on your technical architecture? Work with the software architect to make certain that any business model you propose is appropriately supported.
• What is the pricing model? The business model provides the framework for defining how you’re going to make money. The pricing model sets the amount the customer will pay. You’ll need to consider such things as volume discounts, sales and/or channel incentives, and so forth. Pricing choices may also affect your software architecture, so make them carefully.

As you develop the answers to these questions, you’re likely to find that the best way to reach a given target market will require a variety of changes to your current business model, licensing model, and software architecture. You’ll have to rank-order the changes in all areas of your product so that you can reach the largest target market. The benefits are worth it, for creating the right business and licensing model for you and your customers is the best way to maximize profits while increasing customer satisfaction.

I recently read an article (I think in Fast Company) quoting Penn of Penn & Teller that he never does business with anyone he can’t trust with a handshake. I really agree with this. I just closed a deal for some additional work with an executive of a division of Emerson Electric via an email handshake. It is among the reasons I like working with this person so much — he knows how much structure is needed for the kind of work that Enthiosys is doing for his division. More importantly, he is trustworthy — I know that when the work is done, we’ll get paid. And we don’t need a 20 page contract!

Scott Gilbert and I just spent a some time trying to pick the best time frame for our next Customer Appreciation Day. Our first one was held Sep 23, 2005, and we were thinking that another time of year would be better.

As it turns out, this isn’t that easy. There are a lot of events and conferences during the year, and you don’t want to clash with a conference that you know your customers are going to attend. Picking dates at the end of a quarter are difficult because of end of year financial cycles. Picking a date that clashes with a holiday like Thanksgiving or Memorial Day is a non-starter. Then, you have to be careful of your own family events, like birthdays. And there is no way to pick something that works for everyone, so you have to accept that you’re doing your best.

We decided that for now the middle of September is still the best choice. We may change it, in the future. The experience, though, was helpful, in that it gave us another chance to consider the world through from the perspective of our customer.