The hardest thing sometimes is not looking at a product that’s being put together as a Developer. And for some reason, this post has been one of the more difficult for me to write, hanging out half-done for longer than I’d like. If there’s just one single thing that you’ll take away from this post, it’s

Stop asking or answering Can we build something? Start asking or answering Should we build something.

No, seriously. Ideation is your core – or, as I’ve come to say when talking with the devs, I will ALWAYS ask for the moon – you need to tell me what you need from me to build the rocket. I’m fully prepared to get things de-scoped because I know we aren’t ready for the work, but if I don’t ask for something upfront, I already know the answer is no.

One of the hardest things that I’ve had to learn is to stop asking if we can build something and whether we should build something. While I still open up Developer Tools in a browser occasionally, I do it more on someone else’s site to see how they built some cool feature than anything else these days. It wasn’t easy to give up, especially in the first year of moving over to Product. I kept trying to forcibly step away from the world of development, from keeping all my “normal” programs off of my work computer to limiting my contact with folks that I had worked with and were friends with for years. Anything to help put a layer between my new role and my old one. Needless to say, all this did was make myself question whether I was cut out to be Product and my lunches a little lonelier. I kept reading on how to be a Product Manager from a multitude of blogs and books and kept berating myself because I kept thinking like a Developer.

I had an epiphany one day at work which finally helped me see the difference. We were trying to come up with some new features on a few products in the portfolio, mine included to offer as incentives for a rather large deal. We had been in and out of a conference room for a few days, white-boarding out all of the different scenarios that would work and not work for both our product roadmaps and this large deal, when someone asked the VP of Operations if we could do something drastic to a product to make it more appealing to the potential sponsor.

Now this something was completely technically feasible but would have completely shifted a product’s roadmap off track, possibly even destroying the brand trust that we’d built up over years. After the Operations VP answered that it could happen, I asked whether it was a good idea to shift the brand that far away. It was a bit of a gut-punch when I realized that while I acknowledged the development side (Can) my instinct was to ask if it was a good idea (Should).

Now, to be honest, I was always a bit of a Question Authority kinda gal even when I was a developer, but this was when I felt the shift finally to feel a bit more like a Real Live Product Manager. Not to say that technical feasibility isn’t something that product needs to ignore, but looking at a product path from a different point of view is helpful to find out if that shiny new thing is right for the product is a great place to start. Once you can get past Can and get to Should it will feel the same to you, I’m sure.