What is the Agile Methodology?

What is the Agile Methodology?

Earlier this week, we discussed the Waterfall methodology and today we’re going to go over another popular methodology in the industry called Agile. Agile is an extremely iterative approach to product development based on the Lean methodology that rapidly delivers a product in small batches.

“Agile is an iterative approach to product development that delivers a product in small batches.”

Click To Tweet

Many new startups find Agile to be a preferred methodology because Agile relies on a high level of customer involvement and thus the product is much more likely to be in tune with what the market wants when the product finally ships.

 Traditionally, large companies with complex products (think Microsoft and their operating system or Nasa and a space rocket) couldn’t launch their software in pieces or else the entire product wouldn’t work properly. These companies had to ship products in a predictive manner by carefully planning through all customer use cases / edge cases. Continue Reading

What is the Waterfall Methodology?

Waterfall Methodology

When starting new projects, companies face a decision of choosing which development methodology to use and one methodology that has historically been very popular is the Waterfall methodology. Development methodologies are simply a way to organize the workflow of product (usually software) development and there are pros and cons to each methodology. In this post, we’ll discuss the strengths and weaknesses of one specific methodology: Waterfall.

The Waterfall approach is a sequenced method of events that usually follow:

  1. Idea
  2. Analysis
  3. Design
  4. Development
  5. Test
  6. Final Product

A team will first come up with an idea which they will analyze in order to determine and prioritize business needs and requirements. Next, they focus on the design phase where the business needs are translated into technical requirements (i.e. decisions about which tech stack to use). Once all of these business / technical needs are finalized, the team can begin the code development. After development, the team begins code, systems, and user acceptance testing in order to fix any issues before they deliver the final product. Continue Reading

Maintaining a Product After Launch

Maintaining a Product After Launch

The launch celebration is over, the product is live, and there’s finally time to take a (quick) breather after weeks of intense work. But what happens after a product launches?

The product manager still has a large role in maintaining a product after it launches, and this post will provide a high-level overview and cover several aspects of the post-launch phase.


Perhaps one of the most important immediate steps to take after a product launches is to conduct a retrospective with the team that worked on the product. There are many ways to approach this but most commonly the group discusses the following:

  1. What went well
  2. What could have been improved
  3. Actionable steps for future projects

The retrospective is important because it gets the group talking and allows everyone to reflect on their efforts and voice their concerns or suggestions for improvement. This aligns with agile methodology because the goal is to improve with each new iteration. Continue Reading

What Is a Wireframe?

What is a Wireframe?

Wireframes are a huge part of the website or mobile app design process. In layman’s terms, wireframes are essentially the blue prints that communicate the structure of the site or software being built.

“Wireframes are blueprints that communicate the structure of the feature being built.”

Click To Tweet

They are created before front-end design or coding begin, and oftentimes are very bare bones in look and feel.

Wireframes focus more on the elements and less on the design. These elements include the following:

  • Information displayed
  • How different modules, buttons, etc. are placed
  • Rules for showing different information
  • How different scenarios affect the display

These examples show that wireframes connect the underlying structure of the product or feature to the surface level – which the user sees and interacts with.

Wireframes typically have the low-fidelity look to intentionally show that the design is not final and is open to discussion among the team. Good interface design comes before the finalized design and coding, and getting this right during the wireframing stage is essential to a good user experience. Continue Reading

Do Product Managers Need a Technical Background?

Do PMs Need a Technical Background

A common thread around product management involves how technical a product manager should be in order to be effective. In this post we’ll describe the two viewpoints to this age-old question and cover steps you can take to develop your technical foundation.

Argument 1: Product Managers Need a Technical Background

The most common thread I see among people who share this viewpoint surprisingly centers around the team itself. The argument is that product managers that are technical can form stronger working relationships with the software engineers. There’s a mutual understanding and respect that’s easier to foster if the PM speaks the same language as the engineers.

In the same vein, product managers that know how to code are better equipped to understand the capability and limitations of the engineering team, and can better plan out requirements without under-utilizing or over-utilizing the team. Continue Reading

Managing a Product

Managing A Product

Recently one of my co-workers shared an excellent article that explains what exactly a product manager does. I think it’s one of the clearest and best articles I’ve read about managing a product, and if any of you are interested or even curious about product management, I’d highly recommend checking out “So you want to manage a product?” on Medium.

I wanted to share some quotes from that article which I personally learned during my time as a PM and include some of my own comments – hopefully it’ll provide more info about an awesome field!

When you begin managing a product that has at least one customer, you quickly learn that your job is much larger than even the fullest-featured product. Your job is to deeply understand the problem that your product aims to solve then chase the moving goal of solving every nuance of that problem. You will always have too many feature requests and too little time. Too many bugs and too little time. There are always things to do. Continue Reading