Adventures in home working

Back in September of last year I wrote a post on the lack of support for authenticated RSS feeds and the BIG issues that this was going to cause enterprises trying to do rollouts this year. 

Jon Udell recently mentioned this and the comments and his post are quite useful.  In particular the clarifications around the behavior of Outlook 2007 and the common feed store.

What surprises me is that people consistently seem to think that authenticated RSS is rare, on the Internet maybe - but definitely not in the enterprise.  Although the comments do show that a lot of people and a lot of readers do support authenticated feeds I suspect that most of them will only work with Basic Authentication over SSL.

Yesterday I posted some of my own ideas on improving product management.  Today I thought I would share a few of the better articles I have read on the topic, and contrast them to my own ideas.

First up Kathy Sierra has a post on leveraging the community to to help build a more effective community around your products, its a good read and one of the topics she talks about is using the community to help with product design but she goes way beyond that.  I am a real fan of building community, I’ve done it several times and every time I find we get much more back from the community than the investment we make, but best of all it really is a win win, because the community gets much more back in total than they invest as well.  The thing I like most is that everything seems to get easier, rather than the sometimes difficult customer-supplier model it starts to feel much more like a real partnership and sometimes even like a team.

I have a few posts on the power of community, this one in particular

Next up the inspirational Ismael Ghalimi describes how he is using demand driven development, his approach is very simillar to the one I proposed, although he’s not using some of the market driven aspects that appealed to me.  He restricts his scope to custom features, which is a great place to start:

The main idea behind Demand Driven Development is to syndicate the development of custom features among a group of customers who need the same features and are willing to pay for it. Here is how it works: customers get access to a detailed product roadmap and can suggest the addition of new features to it. Upon review by the vendor, features that make sense get added to the roadmap, but no delivery dates are committed for them. Instead, customers can bid for the development of specific features, indicating how much they are willing to pay for which feature, assuming that the feature could be delivered within a certain timeframe. Multiple customers can bid for the same feature, and once enough bids have been collected to fund its development, the vendor develops the feature and delivers it to the group of sponsors, three to six months before anybody else gets it.

Ismail has recently provided an update to his original post which he titled How To Outsource Product Management and it seems to be going very well.  I liked this quote:

Product Management is one of the most critical functions for any enterprise software company. As a product gets used by more and more customers, requests for new features start to pile in, and the job of a Product Manager is to prioritize them in order to meet customers’ needs, while avoiding feature creep. During Intalio’s early years as a company, we found it very difficult to manage this process. Too many resources where allocated to the development of features that very few customers actually needed, while features that could have made a significant difference on the market did not get developed, for lack of available resources. We only managed to solve this problem when we decided to outsource it, and selected an unlikely outsourcing partner for it: our customers.

In Ismails approach, simillar to mine he has a number of phases:

1. identification, where an initial list of options is proposed, added to, discussed and rated, then they moves on to
2. estimating, where a specification is drafted, effort estimated and a rough cost is developed, then they moves on to
3. out for subscription, where customers bid for the features they want, at least two customers are required for features that seem very customer specific.  Once customers have bid enough money the feature moves on to
4. project, and development starts - once its finished, they either give it to the customers who paid for it 3 to 6 months before anybody else gets it, thereby creating an incentive for customers to contribute to its funding. Or incorporate it into the Enterprise Edition of the product, thereby increasing the value of a subscription. Or donate it back to the open-source community, thereby getting help from the community for its downstream maintenance. In most cases, they do all of the above, in a staged manner, killing three birds with one stone

it’s a really great process and if I ever get a second chance within my company there are some ideas I would like to incorporate.

Finally Kathy provides an alternative approach to the process of defining a set of product features, that can be applied to all sorts of decision making needs where there are many options to choose from and perhaps refine.  It’s a fairly long process, but essentially it has the following charachteristics:

1. The whole process is subject to a time contraint to explot constrain-fueled creativity
2. It involves getting teams to repeatedly pitch other peoples ideas, with the best options being selected.  The clever part of this approach is that because the ideas being pitched are not yours it avoids attachment to your own idea
3. It leverages the wisdom of crowds (diversity-driven inspiration) by having a wide range of independent people involved in the selection process
4. It uses a lot of external inputs to spark inspiration, books magazines etc

I particularly like the idea of repeatedly pitching other peoples ideas and iteratively down selecting them until you get to the subset that you want to take forward.  I think it could be creatively applied to be a much better approach than pitching up a management hierarchy.

This is part 1 - part 2 (to be published soon) looks at some recent articles I have seen that support this approach

In one of my day jobs I get involved with product management and I often find that bridging the gap between our limited investment budget and the poorly defined needs of our customers to be a real struggle, more specifically I find:

1. Customers are not able to clearly articulate their needs, and we don’t invest much in helping them do so
2. The metrics we collect from the services we currently deliver are not designed to give us insights into how that service needs to evolve
3. Customers are largely disconnected from the investment decisions that we make and so don’t feel that they are engaged in a partnership with us that is to the benefit of both parties (this is especially disturbing because we are engaged in multi-year contracts)
4. Neither our customers nor ourselves are well placed to plan for disruptive waves of change, so we both tend to wait until its too late.  For us that means we fail to secure new markets and retain existing ones, for customers it means they miss out on opportunities to gain or at least maintain their competetive advantage

About a year ago I started to think about how we could improve the situation, and I came up with a new approach that would entail placing more control over our investment decisions into the hands of our existing customers, and internal company analysts responsible for spotting disruptions.  In more detail I proposed the following:

1. Our customers are engaged in long term relationships with us, are motivated to help us and our fairy representative of the needs of future customers.  This means we can largely trust their motivations
2. We can get a fairly robust short list of potential investment areas through our research into emerging trends and current service “issues”
3. If we converted our investment budget into virtual dollars we could give it to our potential virtual investors, these investors would be primarily customers, but also a small amout would be reserved for existing service delivery directors and our own researchers into disruptive opportunities
4. Potential investors would get a chance to review our short list of investment areas and suggest additions
5. We would present to customers our investment ideas in an event, in much the same way that companies seeking investment might pitch to VCs.  During the event our potential investors would get the opportunity to grill us, suggest changes and discuss the options between themselves.  Investors might need to sell their preferences to other investors in order to secure sufficient investment to make sure enough funds were secured to make their favourites happen
6. Once the new short list of ideas had been established a second round of funding would probably be required because some investments would not secure enough funding, in addition some customers might decide to invest their own real money to make sure some activities that were really important to them actually happened
7. Once all investments had been decided investors would often be strongly motivated to see them succeed and would hopfully offer to work with us in partnership
8. Customers would then track their invesments and be ready and waiting to “buy” the services once they were complete
9. We would continue to pole customers on their liklihood to buy so as to get reliable demand forecasts and to make sure the solutions were on track to meet their needs.  In some cases we might need additonal investment funds as we moved through the development phases, these re-investments by our customers would keep us on track

Although initially we would probably allocate virtual investment money to customers based on the revenue we got from them a refinement to this scheme would be to reward customers in later years who invested in services that were most successful for us, making the scheme much more like a real investment market.

Unfortunately key stake holders in my company felt that this scheme was a bit too radical and I suspect that they were reluctant to give too much control over to customers.

The ideas for this approach were drawn from many sources, but briefly:

1. CFO magazine had a good article on the use of investment markets for improving decision making in business
2. The Wisdom of Crowds is a useful book that explains how a large group of independent peoples decisions can be aggregated to create decisions that are better than any individual specialist, if you like to listen to your research there is a good talk by the author available here and a great summary by Dave Pollard here
3. Tom Malone talks about the power of predictive markets here
4. Clay Christensen describes the concept of disruptive innovation here and here,  that’s why in my approach I don’t allow existing customers to hold all of the investment but also reserve some for investment in continuous improvement and some for investment in disruptive alternatives
5. Dave Pollard provides a great summary of Christensens work on innovation here

Years ago I setup a collaborative working environment for my team, the idea was for the environment to be really social, we had lots of breakout rooms, large tables where people could sit together, comfy seats, whiteboards everywhere a library area and of course quiet space for when you needed to concentrate. 

Lots of people would ask if they could come and hot desk in the office and in the end we said no because it was getting too crowded.  When I saw this article - and the photo above - about co-working facilities for people who wanted to get out of the house, but not into the office - it reminded me of those times gone by.

I really like the idea, of a space where you can pop in and meet like minded professionals in a great working environment with food and drink.  For me that’s not the office, I work on global projects with virtual teams so I have little in common with the people in the nearest office, and theres no desk space anyway.  

The hat factory is a great example:

The Hat Factory is community office space for geeks and media hackers. We’re a group of open sourcers, video bloggers, Drupal developers, and more who are tired of working from coffee shops and home every day

It’s a really cool idea, and I bet a lot of real social networking goes on here, not just sharing contacts, sending messages and reading blogs!  There’s even a video.

Previous posts I have made about work spaces can be found here and about home working here