Business Analysts: Your Team Is Your Customer, Too
In outside-in development and user-centered design, the entire team firmly embraces the idea that the product is being created for the customers. Everyone makes decisions to prioritize putting what is most important for customers at the top of the list.
Collectively, this is the right way to approach product creation—solve the important problems, make great products (and services), and form strong relationships with your customers.
As an individual team member—as a business analyst, product owner, product manager, or requirements manager—who are your customers? Are you creating the right product for them?
Jonathan Babcock wrote a great article on thinking about your implementation team as your customer and being introspective about what and how you are contributing as part of your team.
While any time is the right time to be introspective and improve, most people forget to be introspective and just do without conspicuous effort on doing better. Culturally, we have New Year’s resolutions as a thematic time to remind us that we should focus on improving at least one aspect of our lives. The start of the year is just an arbitrary time to make a resolution to improve. Teams don’t improve—individuals improve, which collectively improves the team.
Just as the team maintains a customer-centric approach to improving the product they collectively deliver, a business analyst should take a customer-centric view to improving the product—communication of requirements—that she creates.
The most important customers of the business analyst are the team members who create the solution—designers, engineers, and testers. Secondary customers of the business analyst are stakeholders, sponsors, and end-customers (of the product the team creates).
Babcock has a fantastic insight:
I’ve found that seeking periodic feedback from my development and QA counterparts on how well my deliverables are meeting their needs has helped me improve as much as a business analyst as anything else I’ve done.
A business analyst who understands where there is room for improvement in her communication (her product) will immediately start communicating somewhat better and will be able to identify things she can do—investments in her skills, changes to how she creates documentation, engaging team members, etc. Now her job is to balance the do the job work with the do the job better investments.
Agile teams have been using improvement backlogs for a while—explicitly prioritizing investments that improve their collective ability to deliver. Your team can do this too—and you can apply this same approach.
Start with a little experiment. This month, make one thing you do—that your customers (the implementation team) care about—better. Maybe it is making sure that your requirements are measurable (one of the rules of requirements) so that your team knows how to define success for something they are about to build. Next month, pick one more thing. Then repeat.
