For a little over a year, I was on a project with a client in Atlanta building out an API system over an amalgamated inventory database system. It was an interesting experience and a really great learning opportunity. Coming in late January of last year, I joined my team at the client site, literally not knowing anyone. It felt a bit overwhelming as it meant a new team, a new project, a new domain, a new client, and a new city! It felt very much like going to a new job but with the expectation to hit the ground running and contribute to the project.
It’s been interesting to say the least, in that I came in wanting to focus on writing concise but descriptive story cards for the development team. Over the course of the year, I’ve seen the cards fluctuate with the level of information I’ve provided to what kind of information which sometimes means giving more responsibility to the team to search out the answers. I endeavored to write stories similar to how the other BAs on my team wrote them so that we gave a consistent voice to the development team. What made the story writing challenging for me was striking the right balance of giving the right detail of information in that I was initially asked to write out the JSON request and response bodies for the API calls with the right syntax. It was stated that as this is a technical project, the JSON request and response bodies were the equivalent of a UI for this project and was needed to be fleshed out on the cards. Although, I understand the reasoning, I felt that as long as I gave enough context in the card, the development team could start working on the card and build out the JSON request and response bodies. It ended up being a constant struggle with the team to find the right balance (usually through estimation meetings) as differing perspectives were voiced and the team changed (people left and new people joined) which affected how the cards ended up looking going into development. Over the course of the year, I am more confident in how my story cards are written; however, I still anticipate having to adjust them to the needs of the team and the project they are for. In the end, story cards are a conversation piece between parties to implement the “right” thing and my focus shifted into how we could learn that we’re building the “right” thing.
Being a technical BA puts one in a precarious position — how? My background as a software developer lends itself in that I can anticipate questions the development team will ask the business owner. It can also help with understanding how to break down epics and features into stories for the team. However, I should not be doing any technical solution-ing or thinking about the technical stack when it hasn’t been determined. The challenge is fighting the urge to speak up about any technical discussions and decisions and recognizing that it is no longer part of your responsibilities. I am fortunate in that the developers I was working with were open to my suggestions but also being careful in not overstepping the boundaries and making it clear that it was ultimately their decisions. In the end, I tried to remind myself to think big picture and longer term in what kind of value the API system could bring to the business. It was a way of pivoting my focus on technical details to business values and remembering who the software services.
Building out an API system seems fairly basic as a concept right? API calls are your basic CRUD (Create, Retrieve, Update, Delete) calls into a database and it’s just building out the endpoints of what information you want to create, access, and modify. However, we went through a few redesigns of the technical architecture and consequently the API calls to try and make it a good experience for the customers. Redesigns are expensive in that it takes time to re-architect a system and takes away from our velocity and helping to deliver milestones. However, our challenge was that we didn’t have any customers using our backend API which makes it difficult to obtain feedback and make validated claims for the redesign. When we did have customers, we didn’t take the opportunity to connect with the customers in a way to evaluate how they were using the API and that it suited their needs. Our relationship was comprised of helping them integrate with our API and providing technical support.
When I rolled off of the project, we had a working API system that a customer was using to retrieve transportation updates about inventory. It translated to millions of dollars they saved for retrieving that information at their own will. The information provided them value in that they could recognize any problems and mitigate them before they snowballed. Our client was pleased but I personally would have liked to see more use come out of the API system and would have been interested to see how other companies would connect to the client’s and build more business.
- Be more insistent about building a valuable relationship with the customer. With the trust and support of a good relationship, we would be able to learn and watch how their developers use the API and inherently, use that information to improve and iterate over the API
- Building out a product roadmap that caters not only to one customer, but insisting on building out generic features that many customers can use. This approach is not only applicable to API projects, but it’s difficult to change an established client process (which was to build out the product for one customer at a time).
- Find ways to gain feedback from stakeholders. See below for some ideas:
- Build a UI or a number of applications that interact with the API to help stakeholders understand the value of the project and understand how much you can do with an API. (It’s hard to show progress in building an API)
- Using the logs as a starting point to build out a visualization tool as a form of feedback to discover how effective the API is with users
- It would be nice to build out a development community portal
- Future thinking: When scaling the API so that it reaches more customers and look into reducing the onboarding time for users to adopt the API (Can we and should we provide an SDK?)
In today's cloud computing world, many Product Managers will be faced with the decision of whether to open an API to…techproductmanagement.com