There’s no easier way to get respect than to code. If your product is a website you should get accustomed to tools like Firebug and Inspect Element. It’s a great way to show you know the inner workings of your website and that you can do the basics i.e. tweaking CSS styles, editing copy and inserting HTML. There’s an unspoken thought mentality in many scrum teams where team members are supposedly role agnostic and interchangeable such that an engineer can easily do the product manager/owner role but the product manager/owner couldn’t begin to do justice to the developer role. This is often times why it’s considered that engineers can make great product owners.
If you don’t want to code at least know basic principles such as when PNG’s are better than GIF’s, why accessibility matters, why using eval() is not a good thing to do etc.
Another way you can earn respect is by keeping current with general web trends. Often times a developer will be very well grounded and experienced in a programming language but not so strong at keeping current. The latest must use technologies are always changing and knowing about these will earn you respect. Talk about how awesome Angular.js data binding is, share articles on those cool new CSS pre-processors SASS and LESS that your developers haven’t yet had time to read about or show them a tool that may save them some time i.e. Boilerplate or Bootstrap which provide develops a solid development starting point for your website.
Finally specialize. There will be knowledge gaps in anytime whether that be around accessibility or analytics tagging – find that gap and grow your expertise in that area so that you become an invaluable touch point for your developers and an instrumental part of the development process.
One of the trickiest parts of being a developer is being able to keep current. I have a habit of sending out ‘Monday Morning Knowledge Shares’, which are essentially emails that collate useful links and resources I read over the weekend.
It could be a link to recent enhancements to node.js, a relevant podcast from The Web Ahead or a launch of a similar product by one of your competitors/inspirations.
Try and share things that will serve as a useful resource for the product you’re working on. Are you the product manager of a travel website, why not share … to provide an awesome reference of how another team of developers have solved similar problems or user journeys as the ones you and your team are trying to build for.
Show and avid interest in your products technological workings. What are the backend systems that power everything? Why are we using mongo.db? Where are you pulling that content from? What does the automated testing tool look like and how is it used?
Your team will be more than happy to show you how things work as its an opportunity for them to be able to showcase their expertise and talk about a topic that excites them. It’s also a great way for them to learn. They say you don’t fully understand something unless you’re able to communicate your knowledge in a way that others can understand.
You need to show your engineers that you’re not at their mercy. Prototyping can be as simple as a sketch, which can be easily made clickable i.e. using pop app or even using powerpoint! Create beautiful guerilla test worthy mockups using omnigraffle or if you’re a dab hand at photoshop why not create some high fidelity design work and have someone on Fiverr turn it into a clickable PDF. You can even create high fidelity prototypes if you’re comfortable cutting and chopping the HTML and CSS of the website for which you’re the product manager.
Many engineers live and breath code. They spend their entire working day wrapped up inside a code editor or IDE and can build fully fledged applications and websites but this takes time. You will soon find that you’re an invaluable part of your developers arsenal if you’re able to prototype and be a subject matter expert in the world of protoyping and the tools that allow you to create prototypes. I’ve worked with engineers with 30 years of Jave EE experience but are scared to death of anything that requires creative input or that is an emerging web technology or tool – trust me, engineers can be scary but they can’t do everything. Save them time, teach them something…prototype! Let the user pick faults in your early mock ups and not the developers end deliverable.
Make sure you’re developers are part of ceremonies outside of just coding. Give them a voice at backlog grooming sessions and invite them to design meetings – they have a unique perspective to offer and you will benefit from doing this as a product manager/owner. One of the most helpful things about inviting your engineers to such meetings is that they will likely know about all of the complex logic and edge cases that a designers needs to be congizant of when creating designs that you may have missed or not been aware off. They will also be able to tell you early on if something is technically possible or if it will take much more time and cost more money than an alternative; insight that may influence the way you choose to proceed.
Ultimately they will respect the fact that you’re treating the teams as though it were a single unit i.e. ‘one team with one dream’, after all that’s exactly what a product team is.