To build a great product, team members must understand what the product does and why it exists
Editor’s note: e27 publishes relevant guest contributions from the community. Share your honest opinions and expert knowledge by submitting your content here.
This is part two of my experience in building a product from scratch. You can read the first story, How we launched Maqotana.com in one month.
On our second month, we fixed some bugs and built new social features. The features included:
- Voting
- Creating your own collection and adding products to your collection
- User invitation and linked profiles with Facebook and Twitter
- Displaying of user profile and info
Added the Vote Up (heart icon) button and Save to Collection features
However, we still decided not to open the registration or invite users due to the reasons discussed later in this blog.
Technical Notes
For others who have not experienced what it’s like to have a multi-environment development workflow, this is how we do it.
- Wednesday evening: review features that are ready for release.
- Thursday before lunch: release features in Staging environment then start testing
- Thursday afternoon: decide to rollback or not. If the deployment continues, release to production and test.
The toolkits used for production pushes were:
- Git workflow
- Codeception for testing
- Stylesheet cache busting
- Javascript files cache busting using Webpack chunks plugin
Finding Our Product’s Value
On the business side, our focus was to discover if we were building a product people will use and love.
Customer Persona
Last month, part of our weekly meeting was identifying customer persona profiles. Our persona profiles were not complete but we had a few ideas. Our target customer would be: millennials, people who travel often, backpackers and mobile users.
We used this information to find possible people to interview. We were able to arrange 5 out of 7 potential interviews.
One of our interview sessions
It was fun meeting new people over coffee. The discussions were not focused on our app but the interviewees’ experiences. The perspective they brought in was amazing. I both agreed and disagreed on a few topics; nevertheless we learned a lot.
Eat our Own Dog Food
To build a great product, team members must understand what the product does and why it exists.
This school of thought did not suit my team very well. Most of our team members have not traveled enough. So every time we met to discuss what our customers might possibly need, I got a silent room.
This prompted an activity — everybody must become a travel planner. Team members were asked to share their dream vacation and budget. They were tasked to create a detailed travel plan and share in the next meeting. Part of the activity was to use our app to help them find what they needed.
Also read: We launched Maqotana.com in one month, here are lessons and experiences so far
The activity resulted in the following:
- The team understood the struggle of travel and travel planning.
- Aside from making fun of each other’s plan, it was fun to see them finally realizing the next trip wasn’t that far-fetched. It looked like they’ll be traveling in the near future. (I’m hoping sooo, so I can earn a travel motivator badge.)
- Our app sucks. (Not surprised there.)
The Result
The result of the interviews and activities was our realization that we were building a nice-to-have feature. Surprisingly, I am the only person who really googles for apps for my trip!
It isn’t really the end-of-the-world yet for us. There is this other feature that’s in the original pipeline that seems to have more use to our prospective users.
In our last two weeks of the month, we focused our effort to make this feature our main product. While I would not scrap the current app right now, it will become handy in our version 2.0. I’m really excited to see the next iteration.
Lessons Learned
Our experience last month is an example of “Fail Fast, Fail Often” mantra. While I wish I could have learned these lessons sooner, every problem has its own time. In the first month, our problem was “how to start a project” so the solution was “just do it”. However, once we were moving, validating assumptions in our business and product were next. A few key lessons for us:
- All your team members must understand the problem in order to have true collaborative and innovative environment. Some of the ideas we are working on came from the team’s meetings.
- I consider all web-based app solutions as cool hobby projects until we start thinking about our future users. I have done a few hobby projects before that I still use in my day-to-day work but I have not tried to sell them to others. But if we are talking about products to build as a business, finding the right combination of coolness, usefulness and interest will dictate the future (and potential earning) of the project.
- Interviews can save you from ton of mistakes, identify common problems and potential solutions.
With that said, I’m always looking for suggestions and ideas to make our product better. Drop me an email or comment here. I would love to hear your thoughts.
—-
This article was originally posted on Medium.
Featured Image Credit: 123RF Stock Photography
The post After launching our product, here are lessons learned about products and customers appeared first on e27.