As people know … I am big fan of building and maintain this balance between Product and Engineering where …
Product makes sure we build the right thing
and
Engineering makes sure we built it right
(and we help each other to do so :))
But that is only the start. The real magic happens when we get to a point where we are not building faster horses. If the conversation goes wrong it goes like this …
> Customer: I want a faster horse!
> Product: How much faster does the horse need to be?
> Customer: At least twice as fast.
> Product: Let me talk to engineering.
> (later that day ...)
> Product: The customer wants a horse that is twice as fast as the
current one. Can we do/build that?
> Engineering: Hhhmmm ... not sure, but we can try to build one
with eight legs. Maybe that helps/works. Let's build a prototype
and test it.
If the conversation goes right it goes something like this …
> Customer: I want a faster horse!
> Product: Hhhmmm ... may I ask why you want/need a faster horse?
> Customer: Yes. I am going to move to the country side and need
to be able to get into the city in half the time it takes me today.
> Product: That means you not only need to be able to move around
faster, but you also need protection from the weather.
> Customer: Yes, exactly. But unfortunately we cannot fit a cabin
on top of a horse. Or can we?
> Product: Let me talk to engineering.
> (later that day)
> Product: The customer want/needs to double the speed to go from
A to B and also needs much better protection from the weather. What
can we do? Any ideas?
> Engineering: Hhhmmm ... not really, but in the last hack-a-thon
one of the engineers build this thing called a combustion engine.
It has the power of 10 horses. Let's get together this afternoon
and think and talk about this a little bit more.
> (and the rest is history)
Means the magic happens in the intersection between Product and Engineering, when Product brings good requirements to the table and Engineering has creative ideas how to solve these problems with innovative technology.
For that to happen you need to create an environment where creativity can meet innovation (while applying it to good/relevant problems).
And lot’s of companies try to do his by giving hack-time to engineers. My experience is that this does not work. Mainly for the following two reasons …
- there is constant pressure to use this time to fix bugs and/or build features
- even if the engineer (with the help/support from his/her manager) is able to protect the time, it is still difficult to get good millage out of the hack-time, because the engineer has nobody to talk to/work with, because everybody else is busy
Hence my believe that the (I dare to say) only way this can work is to run frequent hack-weeks.
We just did the first Hack-a-thon here at Community. The result where amazing. At the end we had 10 projects and think that at least 3 of them will make it into the product in the next 6 month.
On top of it we figured that while we are at it we can also run a virtual Product & Engineering (P&E) Summit. This was a little bit scary, because we had never done a P&E Summit before (let alone a virtual one), but at the end we found the right themes …
- Align - on where are going.
- Learn - how we will get there.
- Build - the relationships that will get us there.
… and all of P&E carried the event to make it a success.
But as always, sometimes too much of a good thing can be bad. The main lesson learned was that the week was too full. Means next time (and there will be a next time :)) we will run the Summit and the Hack-a-thon in two separate weeks.
Stay tuned …