A year goes quickly when hosting an annual event
In his seventeenth article for The Consulting Balance, Mark shares how being the host of an annual event is a year round undertaking, especially when the event content takes far longer to develop.
Last month I told you the story of our inaugural Nexus conference. For this event we took a group of clients to wine country where we hosted talks from exciting start-ups and presented our own vision of a product-centric development process for enterprises. The key word here is “vision” - presented as such we were able to encourage open discussion around our idea and gather some really valuable feedback to take it forward.
Time flies very quickly when you’re building a company and within a whirlwind six months of our first conference we realized we’d need to start planning our next. Planning such an event and building an audience would take a lot of work - six months to do this was not much time. What really hit me though was how long it takes to build out new positioning for a company. If our first conference had been a promise to make our vision a reality, then we’d need to deliver on this promise for our second Nexus event.
We had been getting great feedback from prospects and clients on our product-centric approach, especially when compared to the old IT-centric approach most were using at the time. Gartner had also published a report in 2017 that touted the approach. It said that “if your organization adopts agile methods (for digital or other reasons), it must also adopt a product delivery paradigm.” The report also published a chart showing what the most transformational things for custom software development would be, ranked by “years to mainstream.” In the “2 to 5 years to mainstream” box, was “Product-Centric Delivery Model.”
Gartner’s report and our customers' feedback were great validation, but we hadn’t yet figured out how we’d actually turn it into an offering. If we were going to talk about this at Nexus, then we needed some firm details fast. Holding us back were some unanswered questions for clients (if they even agreed to our product-centric approach):
Where should clients apply this approach in their portfolio of enterprise applications?
How do clients actually move into a product-centric mindset?
Where to apply the approach
We sensed that the problem we were attacking was the large amount of terrible software out there. It’s often in hardware products that have software - your smart thermostat, stove, TV or doorbell to name a few. While these are things that everyone can relate to, we decided it’d be better to widen our net on user experiences generally. At around that time we found a far more spectacular example in the news.
In January of 2018, the State of Hawaii sent out texts to everyone signed up for their emergency alert system announcing “BALLISTIC MISSILE THREAT INBOUND TO HAWAII. SEEK IMMEDIATE SHELTER. THIS IS NOT A DRILL.” At that time, Kim Jong-un had been threatening to do something like this, so it didn’t seem completely out of the question. As you can imagine this freaked some people out. In one news article, there was a picture of a family who had opened a manhole cover and were trying to coax their child into going down the shaft to seek shelter.
It took 38 minutes for the state to realize the mistake and send out a false alarm text. A post-mortem report was published explaining the bungle. They were supposed to run a routine test with the software, but the user hit the wrong link on the web page, sending out the “not a drill” alert. When you look at the webpage screen shot, it’s pretty clear why the mistake was made. The employee was presented with a jumble of links that all sounded similar - a sensational example of the impact of terrible software.
This eye-opening anecdote helped us make the case that our product-centric approach would be best applied to software that our clients' customers used directly. It clearly illustrated the value of investing more in anything that really impacted their customer experience.
Moving clients into a product-centric mindset
We also began to build out the detailed model that would become our product-centric approach. We boiled it down to ten areas across four groups - technology, people, process and overall speed of operation:
Technology
1. Automating and streamlining the whole development cycle - we were passionate that product teams automated everything in their development cycle so that they could move fast and with confidence. Ideally, this would include everything from requirements, wire frames, and stories through to deployment and production.
2. Build platforms that allow you to accelerate development in the long run - our clients would build many applications to interact with their customers. There were some key components such as payments, logins and mapping that would need to be in a platform so that they could reuse them as they built.
People
3. Product Owners involved in the day-to-day development - great product owners are rare. Teams would ideally need to find business-minded people who deeply understood the technology architecture as well.
4. “T-Shaped people” - these are team members who are deep in a skill (the downstroke of the “T”) but who can also work well cross-functionally (the cross stroke of the “T”). Ideally, all functions would have T-shaped people on cross-functional teams.
5. Integrated, cross-functional teams - in our case, this meant product management, user experience and technology experts who would all need to work together to solve business problems.
Process
6. Get product teams in the field - there is nothing better than getting the whole team to meet directly with customers and understand their experience first hand. The level of motivation to solve the problem skyrockets so people come up with more creative solutions.
7. Shared business outcomes - we tried to get clients to define specific, measurable business goals (this is difficult to do). Examples included raising conversion rates by 10% or increasing customer ratings from 3.5 stars to 4 stars.
8. Agile ceremonies aren’t just ceremonial - we had a group that was passionate about running Agile ceremonies. One of my favorite examples was when developers would grumble about various things that bugged them during a sprint, but then be quiet in our retrospective. We’d hold them accountable to speak up so that we could improve as a team.
9. Finance and procurement buy-in - in an enterprise context, getting finance and procurement to align with the approach is critical. They were often working in an IT-centric approach (“tell me the features we’ll get in 12 months and I’ll negotiate a lower price”). We worked to move them to the business outcome rather than the feature list.
Overall speed of operation
10. Launch before you’re ready then be ready to embrace change - start-ups are good at getting software into the market quickly and then getting feedback. You really want to launch something that delivers value, but isn’t complete. The feedback will usually change your view of what else you need to do to complete it.
Taking our approach to Nexus
At our first Nexus conference we took our vision to our clients to discuss if it’d even float. We now had three hypotheses to form the foundation of our vision. We were ready to take these to our second Nexus for market feedback:
There is too much terrible software out there. Is this the right problem statement?
Our new approach should be applied where customers interact with the software. Do you agree that this is the correct place?
Do the ten components we’ve identified resonate as the right outline for our framework?
These questions alone gave us two days of really spirited discussion with clients. We came away feeling that we were on the right track on all fronts.
We hosted 11 clients at our second event. This was two more than the prior year. While it doesn’t sound like a lot, it was a great foundation for making an annual event and something we could really build on going forward.
The early days of Nexus taught me a great deal. It was a fantastic vehicle to road test our strategy and served as a catalyst for ensuring our plans continually gained momentum. Some things I especially learned included:
Transforming a services company to a whole new model takes years. I didn’t realize while I was in the middle of it all, but moving Nexient from a staff augmentation model to a higher value, consultative model would take several years to complete. Once you’ve got market confirmation that you’re on the right track, you’ve still got a ton of work to build out the offering in detail.
If you are a small, high-growth consultancy, move to a model that will be mainstream in 2 to 3 years. Boutique consultancies have to be ahead of their global counterparts. This is extremely difficult to do, but it’s even harder to compete with the global players on topics that are already mainstream.
Building a brand for an event also takes a long time. Creating an annual event with a loyal following takes a while. You have to be ready to start with a good foundation and build on it over time to get to something that has much more impact.
