Before I joined Lansweeper I used to work with an amazing designer who taught me a lot about problem solving. We collaborated together on a few things and often when I went to him for professional advice, he asked questions that showed the problem in a different light. He said that before you start on any solution, you should always identify the root of a problem. One day he explained it like this:
“Imagine you have been asked by the village mayor to build a bakery. So for example you ask them, why they want a bakery? Maybe the problem is that, on the other side of the river there is second village that has a bakery, and they want bread in the morning just like the people in the second village. However, maybe what they need is not a second bakery, but just a bridge”
When you have the opportunity to work with a good UX team, it can make product management an exciting journey. Watching the marketing stories turn to requirements, mockups, and finally to production and in the hands of the users.
At Lansweeper I am very lucky indeed, the product requirements we build in the Product team, are met with design ideas and mockups that are world class. Plus, the UX team’s commitment to building a complete user experience profile by holding customer interviews and gaining customer insight throughout the whole design process, is the best I have ever seen.
How does this relate when building our API?
I started at Lansweeper in 2019 with the specific purpose of implementing an API to the new cloud platform. This was a new challenge for me, while I had been part of product management previously, I had never been asked to work on something for such a technical audience before. Essentially, the developers who are building our API, are the very same profile as those who will eventually use it. I was used to writing marketing stories and technical requirements for buttons and menus, never for command line framework.
During the requirements phase, we spent a long time talking to customers that had previously requested an integration or API functionality, and also contacted companies that may be considered ‘competitors’ to Lansweeper, to discuss API integrations that would benefit both their and our customers, or ‘both sides of the river’ if you will.
With the feedback from different sources and taking in to account API design standards, we believe that we have brought something very exciting to the Lansweeper party.
Using the GraphQL framework of the Lansweeper Cloud Platform, and an endpoint that allows standard queries of all entities and fields of the Lansweeper data, but also the team have built a bulk export function where you can compact and export your entire Lansweeper data in to a JSON format zip file, ready to be imported in to any platform or integration of your choosing.
Want to learn more on how to API actually works? Watch the video tutorial I created on the Lansweeper Integration API using the link below.
So with the API now in beta, webhooks fully integrated, and development continuing in a number of different tracks, what have I taken away from this experience?
I have learned that when you are designing a product that will be used by software developers, the ‘development’ phase is no longer just tracking the Jira and answering queries about the user stories, it is a richer and altogether more fun experience. It is not only the UX team that ask the difficult questions about how your feature should work, but the developers are bringing their magic to every discussion, and sprint refinement meetings can be the place where you find your next exciting feature.
Torquil from Lansweeper
Product Manager
