I received a good lesson this morning.
As I left my house, the MUNI app showed me that my bus was just minute away from my stop. I sprinted the two blocks to the bus stop and was happy to see the bus pull up as I was about 10 feet away. I slowed my sprint to a walk and arrived to the door right as it closed and the bus pulled away- the 2 block sprint was lost due to the slow pace of the last few steps.
The takeaway here is that if you’re making an effort to push for a result, continue to push and not let up the intensity until the result is achieved. Driving hard 99% of the way isn’t enough, the only thing that matters is the result, which can be decided by that final 1%. Don’t get comfortable.
"Since public launch, we carefully monitored who was signing up, identifying influencers and those that we knew would make good contributions to the community. Tools like Intercom and Rapportive were very helpful…"
Heard this the other day- “It isn’t about building the best product, it is about building the best business.”
This may sound like blasphemy to a product person- but take a second to consider the statement. Yes, we all want our products to be beautiful and full of useful features. We want to be proud of what we’re building, we want others to say “Your product is the rocks!”
However, we must never forget that the end goal of a product is to support the goals of the business. Sometimes what’s best for the business isn’t what’s best for the product. That is why we’re sometimes forced to cut features or release something that is not our ideal vision.
Always be aware of the current goals of your business and prioritize features accordingly to make sure that your product plans align with your business goals. If the business goes down, your product is going down with it.
Some of the best things in my life have occurred as a result of taking calculated risks. Quitting law school and moving to Scotland to pursue my interest in technology was one, proposing to my wife after only 7 days in person and a month of Skype conversations was definitely another. Now I’m taking one more- quitting a well paying job with stable, flexible hours, a job that I know how to do well, one that has offered me a very generous promotion to stay, in order to become isocket’s first product development manager.
Why am I taking less pay to work more hours, in a new industry, where I would have to prove myself all over again? Because I believe that at this stage of my career, being comfortable is not a good place to be.
I have always wanted to work with a startup- to help define a product that will change an industry, to work with an extremely talented and driven team. I want to be the best at what I do. The only way to be the best is by working with people who are the best at what they do. isocket will help me get there. The greatest learning occurs when you challenge yourself- take yourself out of your comfort zone to try something new, this will be an incredible learning opportunity.
I’m not sure what other people would do in my position, but looking at my career and personal goals- I know that for me, pushing myself and taking a risk is the right choice. It will not be easy, it will not always be fun, but in the end I will be a much better product manager, hopefully a better person and will have contributed to an incredible product. I’m extremely excited and can’t wait to get started!
I came across a thread on Hacker News where a user mentioned “Rubber Ducking,” a Software Engineering method of debugging in which the developer explains his code line by line to a toy duck. The idea is that by talking through his code, he is better able to catch errors or solve problems.
I realized that I have been doing something similar to help me solve (or catch) product or UX problems. By vocalizing an issue, you’re looking at it at a deeper level and from a different angle than you would by thinking about it. This is analogous to the old idea that you don’t really understand a concept until you can explain it to someone else.
Here are a few ways that I have used Rubber Ducking (without a rubber duck) to check my UX designs and product ideas:
- explain the issue to another person- the simple act of explaining it to someone else can trigger new ideas or help ID problems.
- write out a step by step scenario of how a user would complete the task that you’re working on. This is especially helpful in finding redundant actions in your user flows.
- walk yourself through the relevant wireframe views for the scenario in question. Click on the buttons that the user would click, pretend to enter the data that the user would enter, talk about each action in the process as if you’re explaining it to a little kid.
- write out the problem that you’re trying to solve- often just a few sentences will trigger something and help you find an answer.
- write out several solutions to the problem.
A few months ago I had the “brilliant” idea of creating an e-commerce business that sold condoms to the Russian market (the idea failed, but that is a topic for another post). I set up a site, found a wholesaler in the USA and placed my first order- $400 worth of condoms. Since I live in an apartment complex, I typically have all packages shipped to my office (I had not set up a PO Box for the business). When placing the order, I made sure to ask the wholesaler to ship the goods in an inconspicuous box- “no problem, we’ll take care of it” I was told.
About a week later I receive an email from my office mailroom that I have a package. I walk over to pick up my box and this is what I see:
To make the whole thing even better, our mailroom is located in a heavily trafficked area of the office so everyone saw this big box and me carrying it back to my car. The guys at work were quick to bestow me with a new title (which I wear with pride).
There are a few takeaways here:
- Don’t send any potentially embarrassing things to your office, even if you’re assured the package will be “inconspicuous.”
- Not everyone cares about the customer as much as you do, so just because they tell you something, doesn’t mean you should depend on them following through.
Hope that made you smile!
Learned a very valuable lesson today- check your assumptions and how they impact your actions. This is especially important in product management. Making the wrong assumption about a user or their needs and goals can lead you to build the wrong product.
So when working on your specs or stories, stop and ask yourself “what assumptions am I making?” and “how can I test that my assumptions are correct?” Doing this check early on, when changes are cheaper, is especially important.
We use Jira to organize Epics and Stories during sprints and the Balsamiq plugin to do wireframing. My team has gone through two iterations while seeking out a better way to link wires to issues:
- Iteration 1: I attached the relevant wires to their stories. It was good because you could see a wire without leaving the story. However, if anything changed in the wire, I would have to dig through individual stories to locate the correct wires and update them. If the same wire appeared in different issues, then the same edit would have to be made multiple times. The process was slow, repetitive and sometimes I would forget to update a wire, which would result in extra questions from dev or QA. It was also difficult to get a complete picture of the product since the wires were scattered among different stories.
- Iteration 2: To fix the above issues, we decided to attach all wires to their Epics and reference the wire name along with a link to the Epic in the relevant Stories. This reduced the number of places to search through in order to update wires and made it easier to get a better sense of how the product linked together- it is much easier to look through or update 5 Epics than 25 Stories. However, it still meant the wires were scattered in multiple locations (the scale of the problem was simply reduced).
I propose the following solution:
Jira should store all wireframes (or other attachments) in one place, a “project resources” page associated with a specific Fix Version for a project. When writing an Epic or a Story, you simply select the resource that you want to attach and it appears in the issue. The user that’s viewing the issue can see all attachments without leaving the issue page. If a resource needs to be updated, you go to the resource page and update it- the changes are propagated through all issues linked to the resource.
Adding wires/attachments to the “project resources” page would be easy- you would just do what you do now- for existing issues through the “More Actions/Attach Files || Add/Edit UI Mockup” menu and through the “Attachment” section of the current “Create Issue” view.
This would solve the two biggest hassles that I’ve encountered: having multiple locations associated with a wireframe or attachment and having to make edits in multiple places when a wire needs to change.
What do you think? How does your team handle wireframes?