When you’re risk-averse, finding the right agency takes months. You follow the Procurement Policy, go out to tender to get five responses, do Dun & Bradstreet assessment, negotiate the contract, and then eventually you get to work.
When you embrace the uncertainty, finding a freelance developer takes days. You message a few on LinkedIn, have an informal phone interview, pick which one can do what you need and get them started.
There’s risk in moving from building a website with a reliable agency who you can have faith will be there tomorrow and next week and next month when you need them, to using freelance developers who can move on and take their knowledge with them at any time. So, how can you manage this risk?
Embracing the uncertainty, you make decisions quickly with what information you have, you break the work into small chunks, do a few pieces of work and then decide what’s next rather than creating a plan at the beginning of the project.
Will it work? We’ll find out over the next few months.
As we figure out how to go about bringing the management of our ecommerce platform in-house and fit it into our existing product management approach, some questions about the roles people play have come up.
In the old way of doing things, as the ecommerce subject matter expert, person with the most Magento knowledge, and owner of the relationship with the agency, the role of Product Manager would have fallen to me. But that doesn’t fit with the new way of doing things.
In the new way of doing things, I’m the customer (which seems a little non-sensical to me as I’m not the end user who will be extracting value), and we’ll have a Product Manager who will collect my requirements and write user stories for the Developer, and a Delivery Lead who will manage development.
It’ll be a challenge for me to give up control to others but I know it has the potential to be better in the future, and I think it’ll be a challenge for the Product Manager and Delivery Lead who are already at full capacity
User stories help us to understand what a customer needs to happen in order for them to achieve their objective.
User stories are one of the outputs in the journey of helping customers achieve their outcomes, but they are only an effective toll for this if the other steps of the journey have lead us this way. If we’ve never spoken to a customer to understand their needs, then we cannot write an authentic user story to express those needs.
Often, rather than having user stories that express the value outcome a customer is going to achieve, we have business requirements that describe the functionality the business expects to be delivered.
Writing business requirements instead
Business requirements are different to user stories. They are taken from parts of the business that haven’t spoken to any customers and express what is expected to be delivered in return for the investment of time and/or money.
Writing business requirements isn’t bad. It isn’t any less agile than writing user stories, but it is what it is, and shouldn’t be falsely wrapped up to look like user stories and pretend that they originated from the customer or to convince us that by delivering against those requirements we’ll achieve something for the customer.
Both are about delivering value
Both user stories and business requirements have their place. They both express a value exchange. One is between the customer and the business, and the other is between two parts of the business. If we want to deliver value continuously (which we most definitely should) then we need to be clear who we’re delivering value to.
Finalising requirements for AX Magento interfaces.
Optimising product pages for Google Shopping Ads.
Meeting with the Digital Team Delivery Lead to discuss working practices.
Discussing Returns and Refunds processes in AX.
Meeting with the UX Team to discuss the rebranding of the Online Shop.
Meeting with the Retail Customer Services Team to set them up on Freshdesk.
Meeting with the Accessories Buying Team to discuss expanding our clothing range.
Interesting stat of the week…
Across the entire product range the average rate of sale is 3.69 units a week, with the top performing 10% of products having an average rate of sale of 28.6 units a week, and the best seller having a rate of sale of 203 units a week.
In the not too distant future….
More coordinated approaches to customer services and logistics.
I’m not sure what you’d call our way of managing work, but this is what we do: We spend two minutes every week moving cards on our Trello board to show what we’ll be working on that week, and then we trust each other to get on with prioritising our own workload and working on with the things that have the most impact.
The Digital Team use Scrum. The Product Owner raises tickets in Jira, writes user stories, and prioritises the work they want done. The Dev team estimate the work, add it to the backlog and decide which sprint to fit it in. Once the dev work is complete the Test team test it and if the work passes it is deployed to the live environment. The Delivery Lead manages it all.
I don’t know what you call whatever it is that we do, but I like it.
The phrase comes from Mind. Their proposition is “We’re here to make sure no one has to face a mental health problem alone”. It makes sense that a mental health charity would frame poor mental health as a “problem” so they can be framed as being part of the solution.
But is calling it a problem negative, is it part of the stigma? Should we use phrases like ‘poor mental health’, ‘mental health issues’, or ‘illness’?
Often, having poor mental health is a problem for the person experiencing it, but as disability campaigners have often said that it is society that ‘disables’ people and prevents them from taking an active role in society, not that they have a physical limitation. Perhaps mental health is the same.
The British Heart Foundation eBay store is probably one of the most successful charity stores on eBay. It has thousands of listings of all kinds of interesting and unique items that have been donated to the BHF to raise money for life saving research into all kinds of heart conditions.
I wanted to build a Chatbot that could search the listings of a specific eBay store and return results based on a user inputted search term. The idea was simple; the bot asks the user what they are looking for, the user enters their search term, e.g. “camera”, and the bot returns all the listings on the BHF eBay store that match.
I broke the flow into three parts: Getting the search results, displaying the search results, and filtering the search results.
This was my first bot using an API to pull data from the web so I had a lot to learn about how to get the search results from eBay. And I didn’t really know how I was going to get the results to display in a chatbot, which listing info was essential and which I could do without, but I knew that with thousands of products on the BHF eBay Store at any one time, the third stage of filtering the listings was going to be essential for making the chatbot useful.
Getting the search results
I started by creating a developer account with ebay to get access to this suite of API’s.
Ebay has an API called ‘findItemsIneBayStores’ but I couldn’t get it to return results for the BHF store. A quick bit of Goggling showed that this API was known to be unreliable so I moved on to using the ‘findItemsAdvanced’ API.
This gave me greater control over the returning results which meant that I could pull results only for the correct store and get the elements I wanted to display to the user: Listing name, image, url on eBay. This API also allowed me to limit the number of returning results and display them in order of finished soonest first. Doing this would reduce the amount of filtering the user would have to do to find an item they were interested in.
So, when the flow was the started, EbayBot asks the user what they would like to search for. The users types ‘camera’
The bot then uses the eBay API to pull back data for active listings in the BHF store that contain the keyword ‘camera’.
Getting reliable search results returned in JSON format was great. Now I had all the data I needed.
The next steps
The next step will be to figure the best way to display these results to the user in the chat flow. I think it’ll probably be a set of image cards that show the listing title, an image of the product, perhaps the current price, and either a link to the listing on eBay or a button to look at a single listing in more detail. I think this user experience decision comes down to whether users are likely to be able to choose the listing they are looking for with the first set of results, which means sending them out of the flow to eBay would be fine, or if the first set of results doesn’t give them enough info to choose, in which case i wouldn’t want them bouncing back and forth between the bot and the eBay website so I’ll make it so they can go into expanded information for each listing. I might also have a look at whether there is a way to identify if they have the eBay app installed on their phone and if so open that rather than link to the website.
If you ever find yourself on a rooftop in danger of falling off having blindly followed when you knew you should be leading, and you tell yourself that next time you’ll make different decisions, know that when that next time came around you at least went up on to the roof having not made the same mistake in the same way.
