ESCAPE VELOCITY

1 - There are a lot of things to do....
1) Adopt a BP / Adopt a developer. Every developer works with a BP on a "let us know each other better". Would work with big customer accounts too
2) Bali holiday: develop in Bali where network connections back to the US servers are slow (latency is king)
3) Create a Domino front-end for the bug tracker.

stw

2 - One of the ideas I tried to advocate at my last company was one in which application developers would be assigned to a given department for a defined period of time. During this time, they would be part of the business team, working with these members on a daily basis, learning about their processes, pain points, etc. It was my belief that the best way to truly be empathetic to the customer was to live in their world. Something like that might be useful here.

Of course, I'm not suggesting that the developers from Westford come take up residence in your company, but there might be something to be said from letting them out of the lab every once in a while to visit customers in the real world and see how those customers are using the products Lotus is delivering. It's true that there is a chasm between our use of Notes and companies that have hundreds or thousands of applications on the platform to run their business (Side note: we do, of course, have thousands of apps, but with so many employees, a given individual doesn't interact with many).

I've believed for many years that the SMB space could be an incredible opportunity for Lotus Notes, but you are correct...we need to answer this issue. I'm not sure there will be a silver bullet, but it's good to get people starting to think about it.

3 - The chasm can only be blamed on the developers if they deviated from the vision and spec handed to them from the product team. Yes, developers work on specs but not in isolation. They get direction from the product team. The product managers and team should ideally act as the liaison between those using it and those developing it.

4 - @Yancy...Yes! I assumed that Nathan was speaking about the entire team involved in the process of developing the products, so I was using "developers" kind of loosely there.

5 - I think Mary Beth Raven has already demonstrated a pretty good model of how designers (and developers) can stay in touch with their customers. Develop personas that represent likely users for the product AND blog often about ideas and alternatives - giving anyone who cares enough a chance to provide feedback before design decisions are made. We have seen that work with the development of the Notes 8 client but NOT with many of the other products, including Domino Designer.

6 - Look at it from IBM's perspective: Lotus Software had seen 14 quarters of successive growth. Why would they think they're doing anything wrong? In fact, why do you think they are? How do we, a group of passionate rabble-rousers, gain the attention of the people at IBM who matter? And how do we convince them they need to change?

It's going to take a fundamental shift in mentality at IBM to get them to peer far enough into the future that they foresee their own demise -- and make no mistake, I think that's where I think they're headed. We tell them both publicly and privately that they're heading down the wrong path, what else are we supposed to do?

Can you tell Marc Jourdain that he needs to send developers into the field for a month each so they can learn how real customers use their products? Can you tell Julie Kadashevich she has to do the same? Or Andre Guirard? And if you can, how is that different than the people who have been saying that for the last 10 years? Why would saying it now be any different than the "you're ignoring us" mantra we've been chanting for a decade? I'm not saying we should give up, I'm just wondering why it's our problem to solve, and what else we can do that we aren't already.

7 - I think that utilizing product managers and key-liasons between the BP/customer community and the vendor (IBM) will only address some of the problem. I'll elaborate...

When I work on a given project, I tend to interview the user community to gather intended usage scenarios. I need to understand how they're currently working today, how they plan on working tomorrow, and the pain points (as Chris B mentioned).

ONLY THEN, can I effectively consider all possibilities and think "outside of the box" to deliver the best solution to the problem that the requesting user community might not have understood enough to ask.
Adversely, when I'm given a project from a project manager that says, "Build this, and this, and it needs to do this and that." - I become a code-monkey and not a developer.

If the development community was given the ability to communicate and collaborate with the BP and SMB customer community, I think that their understanding of the issues that face both groups and their sincere want to address those issues will bleed through into the products.

I think that having the product managers and the key-liasons communicate back all requirements to the development teams both creates a "whisper-down-the-lane" situation while also greatly limiting the creativity of these developers: turning them into nothing but coders.

Products are an end-user solution. Product developers therefore need to understand their target audience, their needs, their wants, and the in-between.

Now, how to do that? Get them more active in the Yellowverse (nice!). Start cycling 6 months on-product development and 6 months on customer usage evaluations and triage. This rotation will allow your teams to see how what they do "back in the office" plays out "in the streets", while giving those "back in the office" the ability to employ their "street knowldge" in their product development practices.