It's been nearly six months since I moved from Client Success to the Product department at SalesLoft. I learned a lot in the first 30 days alone, but the next 150 days have been a blur of discovering how different methodologies work, what "user experience" actually means, and of course working crazy-hard to deliver new or improved features to our clients.

Because I'm a writer at heart, I thought I'd document this journey, all of the ups and downs and what-the-heck moments, and share it with the world. Maybe it'll help someone else. It'll certainly be good for a laugh later!

THINGS I'VE LEARNED IN THE FIRST SIX MONTHS OF A PRODUCT ROLE:

Involve product design first, or at least early and often. If you have design talent available to you, take advantage of it. This includes UI and UX, they both have important places at the table, and can make not only the end feature better for clients, but also improve the engineering/building part of the process. Engineers tend to like clear directions, and nothing's clearer than a layout of exactly how a feature will look at every stage. Also, the design team knows the why behind button selections, verbiage or screen flows, and can back up their suggestions to stakeholders and engineers with data and training. You want them on your side.
Process is important... Process keeps you on track, helps you set clear expectations for everyone in the group (including yourself!), and gives the stakeholders and rest of your organization visibility into blockers, small wins and timeframes so they don't spend hour each day asking you when something will be delivered. So yeah, process is important...
...but so is knowing when to adjust it or let it go. Not all processes are created equal, and not all processes will work for you or for your team. This is not to say that your process should be constantly changing, but that sometimes certain processes should be tweaked to match how you and your team work best. There are pros and cons to two of the major methods alone, and your right fit may be somewhere in between, or not those methods at all. Spend time learning how you and your team prefer to operate, and how you work the best.
Listen first, then talk. This is actually a principle from Stephen Covey's book, "7 Habits of Highly Effective People." Habit #5: Seek first to understand, then to be understood. As he outlines, most people listen with the intent to reply, not to understand. This can cause you to miss something key to the discussion, or interpret it incorrectly, because you've already decided what the other person means. Full disclosure: This is one of the hardest things for me. I'm a talker, a sharer, and I always have a lot to say. But I work every day to listen to my team and let them make their points or ask their questions without my input or spin. I'm not great at this but I'm improving. And we've had really valuable discussions and feedback because of this that have made our product stronger and better.
"User experience" isn't just where the dropdowns and buttons go (although that's part of it). UX is more about how people feel when they use your product. Do they feel frustrated? Successful? Happy? Annoyed? User Testing Blog has a great article on how to define UX design, and they say that it's "the process of designing (digital or physical) products that are useful, easy to use, and delightful to interact with." The word "delightful" conjures up a pretty specific feeling of joy and ease to me, and I try to keep that feeling in mind when I'm crafting a feature or a flow for clients.
Think literally. I mean, actually literally. Engineers are literal. If you want something to be alphabetized, make sure it is not only outlined as "list to be alphabetically sorted" in the acceptance criteria, but that it's also that way in the example mock-up. Don't assume the engineers will just intuit how it should be. They trust that you and the design team are doing your job in giving them certain parameters, and will create exactly what you gave them. That's their job, and they're good at it. Don't make it confusing for them.
Engineers like donuts, but they also like cookies. They can be bribed with said cookies. You may want to preemptively bribe them so you can build up some credit for when you inevitably have to change a spec at the last second. (Not that that's ever happened...)
I still only sort-of know what’s going on.