In Blog

Hothouses

Back in 2004, BT introduced a new way of launching product ideas that involved the customer right from the outset. They were known as hothouses. They coincided with the a shift to more Agile ways of working. But, they had a profound effect right across the business. Prior to the introduction of the concept, BT had already started making sweeping changes to the way projects and programmes were run. They had abolished over 4000 projects into 29 programmes. That intention was to reduce the amount of work-in-progress and improve the focus of the leaders. Part of this was a move to ensure people were only allocated to one initiative rather than being assigned to many different project codes. Again, focus was the goal. With the introduction of hothousing another goal was introduced – to get all deliveries into 90 days. In other words, speed! But there was another, deeper, goal – to involve customers right from the beginning of any new idea, and then throughout.  The principles for a BT hothouse are below.

Principles required in order to qualify as a Hothouse

  1. Real customers representing the target market need to attend the Hothouse.
  2. A CEO or a direct report (DR), and CIO needs to be the sponsor for the three days.
  3. The Hothouse should include such participants as Customer Experience (CE) Director, CE Technical Leads, E2E Testers, Service Delivery, Business Sponsor and the Platform Technical Leads.
  4. The current situation needs to be shown to the whole Hothouse in an End-to-End Customer Experience video.
  5. The problem to be solved needs to be clearly expressed with clearly defined and quantifiable business benefits and improvements.
  6. There should be between 3 and 8 teams addressing the same business problem.
  7. There needs to be a maximum of 8 people in any team and the team leads should be technical people.
  8. To enable the highest level of productivity the team needs to include no more than 2 business partners. Any “Specialists” at the Hothouse need to be allocated to a team.
  9. Allocation of the membership of each team needs to be by an “auction” of people on the first day of the Hothouse.
  10. There needs to be direct competition between teams in the Hothouse.
  11. The competitive prototypes will be judged by the customers, sponsor, programme and the other participants.
  12. There needs to have been prototyping and demonstrations of the solution to the business problem on every day.
  13. The CEO or DR should open the event stating the business problem and close the event by selecting the solutions to be developed further.

But there was more. The intention of the hothouse was as much about collaboration, innovation, and sponsorship as it was focus, speed and customer focus.  By ensuring Business Leaders were involved with product and software engineering teams, plus the introduction of real customers, it created an environment that encouraged a huge amount of iteration, feedback and quick decision-making.  Every day people would build something as a solution to a real customer requirement or business need, and every day they would get feedback.  In fact, in the largest hothouses, there would be 8 teams presenting every day – they might all have attached a different part of a problem space in different ways and this creates a whole host of ideas for all the teams going into the next day.  This allowed all parties to refine their ideas of what success might be.

Teams didn’t always compete.  They often collaborated.  Including with the customer and the business too.  At the end of the 3 days, the whole group would have learned a huge amount about the customer problem and potential solutions.  They would have tried things, learned stuff and innovated.  The idea was that ideas could be validated really quickly.  And based on real working solutions that could either continue to live or be dropped if they didn’t quite hit the brief.

The hothouse was just step 1 in the 90 day challenges.  The goal for the ‘winning’ idea was to get them into the hands of the customer 90 days later.  From Concept-to-market (C2M) in 90 days.  The beauty was that these events had the backing of the senior decision-makers and the customers which allowed people to move freely and quickly.  Everyone was aware that in 90 days you were probably only going to deliver a first version that needed refinement.  That was the point.  A real customer need with a team prepared to create a solution and test it in 90 days.

These events were tough.  But, rewarding.

Hackathons

During the late 2000s and into the present day, similar events are happening throughout the world – they’re known as Hackathons (sometimes hackfests or code fests).  In a similar way to the hothouse, a problem or opportunity is fed into a hackathon and teams would get together for a day or more to build real working solutions.  It’s the beauty of software – things can be built and tried incredibly fast.  The Open Data movements have led to lots of Hackathons where public information and APIs are provided into an environment to see what developers, engineers and product designers can come up with for the good of society or for business opportunities.  Again, the goal is to encourage very rapid feedback with a huge amount of collaboration and fun!

Today hackathons are used throughout the world to solve major problems and encourage a huge amount of innovation.  They are used by Governments, Agencies such as NASA and even the largest and most innovative companies like Google, Microsoft and Facebook.  Apparently the ‘Like’ button came from a hackathon.  For more information on types of hackathons take a look at wikipedia.

Doing things differently

Sometimes a large, visible change of working processes can be a great catalyst for a large cultural shift.  These sorts of events are amazingly valuable to encourage ideas, collaboration and camaraderie across company boundaries.  They are perfect for product development and a way for bringing new ideas to life.  If you’re still trying to get your agile transformation going, consider kickstarting it with a hothouse or hackathon.

 

 

Subscribe to new blog notifications



Philip Black
I'm the Chief Operating Officer for Emergn and Product Manager for VFQ®. In between my day job running Emergn and working with our clients, I write content and develop courses for Value, Flow, Quality®. I’m passionate about helping people change and own the way they work and help them develop their own passions.
Recent Posts

Leave a Comment