A few months ago, I was given the task of delivering a product using technology that our company had never worked with and that our team had never encountered. My first thought was that it was highly risky and that there was little chance of success. But my second thought was: “OK, if I don’t know, it means that I should find somebody who does know and ask them for assistance.” And so I began the journey that I would now like to share with you.
Our task was to deliver an extension to our core product in a technology that my current team had no expertise in. Our teams are great. They are smart, hardworking and very professional, but when the requested deadline is just two months away and requires new technology skills, it is unrealistic to expect them to succeed.
Throughout this post I’ll use the implementation of a mobile shopping application for a white-label ecommerce platform as my example for product development when you don’t have expertise in the technology.
Develop In-House or Find External Expertise?
There are a few aspects that should be considered when making the decision whether to develop expertise in-house or look externally for the necessary skills.
1. Relevance to the Core Business
The new technology may deliver important enhancements to the product, but it may also be far from the core business, or be relevant only to a specific segment of your customers. Perhaps the technology is niche and you want to just test the market to see how it reacts before investing significant resources or recruiting new team members.
2. Learning Curve
Learning new technologies takes time, much more time than you expect. You will not only need to invest in learning the technology, but you must also select your approach, understand best practices, sort out your licensing, setup IT infrastructure (even for cloud-related technology). And when you start on this path, you can never be certain what the required effort will be, and most probably it will take you more time than someone who has implemented similar functionality a dozen times before. In our ecommerce example, learning about mobile platform development may require an investment of time, as well as the recruitment of developers who are experts in the relevant technology and practices, as well as the adaptation of the technology already in the company.
3. Timeframes
My business team wants all new products delivered yesterday, always. I’m sure your business team does as well. So timeframes are very important. In cases where the technology is new it is very challenging to commit to a reasonable timeframe, as everybody (understandably) starts to add buffers due to the lack of knowledge of the technology. Usually development managers don’t like to put too many people to work on a new technology at one time, and if one of those few people goes on a ski vacation in the middle, it is difficult to find a replacement.
The only obvious choice for me was to select a team with expertise in the technology, and then assist them with understanding the business. I thought that if we had a great product owner who understands what should be done, and great developers who know how it should be done, then we would be in a good position – however we found that this is not entirely true. A good team is one that does not just complement the knowledge of another team – it must also overlap it. The product team should know about technical limitations, and the developers should understand business-related flows and how they affect each other. So when the product owner doesn’t know the technology’s limitations and the developers don’t fully understand the business, you should be ready for a challenge. If you’re following the approach of bringing in external engineers with the required skills, keep in mind there will always be something that the dev team doesn’t understand or hasn’t explained to you, and that you need to find those things work through them together.
User Stories
In order to overcome this challenge I suggest using the two following approaches. One of them is to create a classic PRD document that can be used for the definition of requirements and the basis for further statements of work and estimation. The second way is to create user stories, which you may be familiar with from agile methodologies.
For more complicated stories I’ve found it’s good to add a section that’s a practical illustration of the story. This section contains step-by-step instructions for review by the team during weekly meetings, and developers can run through a scenario and understand how you expect to test the product. We selected this user-story approach for the following reasons:
1. Flexibility
A list of user stories can serve as a backlog for the team to select tasks from, however as product owner you set the priorities. You need to get effort estimations for the development as you need it, rather than as the developer understands it. You breaking down your PRD into the stories, you can also ask the external team to provide effort estimations based on your understanding of the functionality. It means you will save a lot of time when you negotiate the scope of the project.
Let’s imagine we have cross-selling and up-selling functionality in our ecommerce platform. From our perspective it is the same component that presents different lists of items based on what the user has selected on the main screen. External developers may consider this as two tasks – cross-selling and up-selling – and assume it requires two development efforts. But we can define this functionality as the user story of cross-selling and up-selling, with potentially identical components, activated using a different set of parameters according to the scenario.
2. Acceptance
You define how you test, and this creates the framework for common understanding. The acceptance criteria and the practical illustration allows the developers to perform tests themselves before they deliver the result to you. During our weekly meetings, we demonstrated the way that we performed acceptance testing, and the dev team were able to prepare for future meetings based on this.
Here’s a simple practical illustration from our ecommerce platform: “Login to the platform, select an item from the main page, select an item from the upsell component and go to the checkout page.” This practical illustration implies that selection from two different components is important for us, and we are going to test this during the weekly meeting.
3. Technology Aspects
This list of user stories will also allow you to learn about the technology. Imagine that you have three stories in your backlog. As far as you can tell, the first two require a similar effort and the third one is significantly larger, but the team’s required effort is inconsistent with your understanding e.g. the first and the third are equal effort, and the second is extremely high.
That may either be because the technology works in a different way from your understanding, or that the team didn’t understand you properly. In our ecommerce example cross-sell and up-sell can be seen as a relatively simple component because it just renders a list of three items in standard resolution. However, rendering of the items in the mobile app should be adapted for each supported resolution of the device, and will probably take extra effort.
We found that this list of the stories served as an efficient way to communicate with developers and clarify our intentions. The only drawback we found with such an approach was the lack of the complete picture for the development team. Each user story describes a separate piece of functionality (or at least a separate workflow), and lack of connection between stories meant that the development team found it hard to understand how all the components should interact. They found it very helpful when, in addition to the story list, we provided sequence diagrams and flow descriptions.
In summary, it was an amazing experience for me from which I learned a lot. Bear in mind that clear communication with the dev team is always of the utmost importance – more so when they’re in the process of learning about your business, and you’re in the process of learning about a new technology. User stories can serve as excellent basis for such communication, but also bear in mind that complementary documentation should be provided to form the full picture in the developers’ minds.
Comments 0