... latest news about Spotlight

News for May 2013

Friday Findings: Lean Software Development

Person running

Posted by: Seth Weedin

Entrepreneurs and anyone who has been involved with a startup company know how fast-paced of an environment it is. Unless you are one of the lucky ones who can bootstrap your business initially, lack of resources causes everything to be accelerated. This includes software development.

Lean software development is a term used for developing software applications through constant iteration or release of new code. The idea is to eliminate waste in the development process, leading to faster development and earlier project delivery.

If you are engrained in the traditional waterfall style of development, changing to lean is a fully involved task. Today’s Friday Findings offer 10 resources that can help you understand how lean software development can be advantageous for your startup business.

The Findings: Lean Software Development

  • The 7 principles of lean software development have remained the same since Tom and Mary Poppendieck transitioned them from the manufacturing world to software development. Their website offers a short, valuable explanation of each one.
  • This article from looks at using lean tools in a software development environment and how to apply them properly.
  • Microsoft conglomerates a number of resources to explain the lean development methodology in detail. Possibly a great starting point for learning how to transition development practices to a lean style.
  • John Vajda, PMP and CSM, outlines the 7 principles of lean software development and shares 22 tools to make it work in this Slideshare presentation.
  • Kanban can be a great way to visually map out your software development project. Here’s how to implement lean software development using Kanban.
  • The difference between all the software development methodologies can be difficult to understand at times. Here’s a more visual way to see the difference between Waterfall, Iterative Waterfall, Scrum and Lean Software Development.
  • Charlie Rudd, CEO of SolutionsIQ, looks at the debate on whether Agile and lean software development are similar or different. Fact is, they share many of the same principles.

At Spotlight, we use the lean development process to release new updates and code at least weekly. This helps us respond to customer feedback quickly and get the updated product into the hands of users as soon as possible. The quicker the product reaches your target users, the quicker you can monetize.

Has your business or team implemented the lean software development methodology? Leave us a comment with your experience thus far and how it has worked!

For more information on Spotlight Software and our services, please contact us or visit our FacebookGoogle+LinkedIn, or Twitter profiles.

Friday Findings: The MVP Process

Posted by: Seth Weedin

Earlier this week, we posted an article discussing the minimum viable product (MVP) and how to turn it into something that is ready for your entire target market. Here at Spotlight, we took a two-phase approach in developing our people and project manager app, starting with the MVP and finally releasing to the masses with our minimum marketable product.

Lean startups vary in several ways in how they approach the release of a new software or mobile product. One size doesn’t fit all and any of these variations can work. The important thing is to remember the underlying concept of the MVP process from Eric Ries: to provide a scientific approach to creating and managing startups and get a desired product to customers’ hands faster. The end goal is the same; get your product in the end user’s hands faster, get feedback on how the development of the product should unfold moving forward.

We piggyback off this theme for today’s Friday Findings to share other expert perspectives on how to manage the MVP process. It can often make or break your business.

The Findings

  • Not exactly sure what is entailed when creating an MVP for your new business? This article answers 4 common questions about the process.
  • Here’s how one company developed four MVP’s in less than a year to get it right. Sometimes to get the right fit, you have to throw everything out and start over.
  • If you are just starting to think about developing a new product and wondering about cost, Forbes looks at four methods of MVP development and what to expect for spending.
  • Here’s the entire MVP process from initial development to customer feedback and iterations mapped out in a informative infographic.
  • How will your idea resonate with the early customers? Steve Blank discusses the best ways to find out if your MVP is worth it or not.
  • Sometimes MVP’s are released that are absolutely dreadful to work with. Here’s how to turn your product into something users enjoy and make it ‘delightful’.
  • This is a very short, fun take on Apple’s MVP from Andrew Chen. Remember, your MVP doesn’t have to be lightning in a bottle right away.
  • See how to actually implement a MVP from a more technical standpoint in this article from GROU.PS Chief Architect, Emre Sokullu.
  • No discussion on the MVP process would be complete without wisdom from Eric Ries. Use this article and video as your ultimate guide to releasing your first product.

The trick is finding a MVP development process that fits your business and potential end users. But the overall concept of developing the MVP and getting it in the hands of your users will save you money, time, and sanity.

For more information on Spotlight Software and our services, please contact us or visit our FacebookGoogle+LinkedIn, or Twitter profiles.

The Minimum Viable Product: When is it Marketable?

Posted by: Seth Weedin

Minimum Viable Product

Build Your MVP in Steps

“Lean startup” is a popular phrase in today’s entrepreneurial world and for good reason: it works.  The official definition to the lean startup methodology from Eric Ries is “to provide a scientific approach to creating and managing startups and get a desired product to customers’ hands faster.” This process involves developing a minimum viable product, or “a version of a new product which allows a team to collect the maximum amount of validated learning about customers”.

So a minimum viable product (MVP) is a way to get your product into the hands of users faster and use their feedback to continuously innovate. There is no better validation on whether your product has legs than honest feedback from your target market. They will be brutally honest. The key is to make sure you listen, as they will stop you from wasting money on developing a product that sucks in the first place.

When we were in the process of developing our MVP for Spotlight People & Project Manager, we took a two-phase approach. First there was the MVP phase, which we used to gather beta users and early adopters for thorough feedback. We used the feedback to continuously iterate and add functionality. Then there was the minimum marketable product (MMP) phase, which is a period where the product is out of beta and can be marketed to new customers. You will still be iterating and using customer feedback, but this product can have more marketing dollars pumped into it. Some people use these terms interchangeably but we separated it into two phases.

It’s often difficult to judge when the time is right to release a MVP and then MMP. Here we look at each one and some differences to help you in the process of building your lean startup.

Minimum Viable Product

The MVP is initially used to validate your product idea with customers. Here we look at three key areas that can help you determine if it’s worth moving forward with your product.

  • Value – Does your minimum product provide enough value that people are willing to use it? If you have a hard time attracting traffic to your product’s website through a smoke test PPC campaign, it’s obvious something needs to change. Or maybe the idea just isn’t going to perk much interest, ever. On the other hand, if you receive good traffic and a number of signups for early beta testers, chance are you’re on the right track. This initial user feedback will give you the information needed to determine if it’s worth spending the capital to move the product forward.
  • Future Benefit – As you move through the early MVP phase, you’ll get an idea of whether early adopters are actually using the product and coming back for more. Do they believe your product shows enough future benefit to keep using it? Users should be able to see the potential of your product with an MVP even if the functionality isn’t there yet.
  • Feedback– Feedback from beta users and early adopters is a two way street. You provide them some incentive, such as free use of the app right away and possibly in the future, for their feedback and suggestions. This will help guide your future development goals beyond the MVP. Instead of throwing in features that your team thinks would be beneficial (often called ‘feature creep’), use the data at hand from those using it everyday in real business situations. If the early adopters have suggestions for improvement, it will likely benefit your entire target market as a useful addition for the future. If they have no feedback at all, it’s probably time to reevaluate your product.

It’s important that early users can identify the vision and promise of the final product through the MVP. If they can’t see it or don’t think it’s worthwhile, gathering feedback and data will be tough.

Minimum Marketable Product

As previously mentioned, we separated our development roadmap into two phases, the second being the MMP. As our application evolved through the MVP phase, we asked ourselves, when is it ready to be released to the masses? Now that you’ve verified the idea with the MVP and people are getting value out of it, how do you know when the product is ready to turn on the marketing funnel? Here are three areas of your product to consider that help with this decision.

  • Reliability – The MVP phase is used to work out a lot of major bugs and server issues in your software product. While your beta testers will be understanding of outages or business crippling issues in the early phase, regular customers will not. Ensure your product is 100% free of any show stopping bugs that will deem it unusable. When you release a MMP to the world, people are going to rely on your product when they sign up, whether it’s for business or pleasure. Don’t release a product that is going to frustrate them with reliability issues.
  • Scalability – Ensure whatever platform you’re product is hosted on is fully scalable for a flood of new users. While most new startups won’t get overwhelmed with new users as soon as the MMP is released, scalability needs to be something that is worked out during the MVP. There is always that chance your product catches on quickly and the signups start rolling in. Make sure the traffic can be handled before releasing your MMP.
  • Performance – Nothing is slow these days in the world of technology. If it is slow, people don’t use it and definitely won’t pay for it. Test the performance of your product every which way before releasing an MMP. Studies show that 250 milliseconds can make the difference between someone visiting your website or a competitor’s. Chances are there will be multiple users hitting the system at once and any delay in response, even seconds, will frustrate them. Nothing good comes from frustrated users as soon as you release your product.

While there are several more things to consider before releasing your product to the entire market, these are three vital ones. You want to be prepared for anything when moving out of your MVP and into a marketable product release. While you will continue to iterate your product with new features, updates, and improvements, an MMP can be released when you’re prepared for the unexpected.

No matter if you are building a MVP or ready to release a MMP to your target market, the key to all of this is building a product that solves a problem. If it doesn’t solve some type of problem, people or businesses won’t use it. Starting with a MVP and morphing that into a MMP after honest user feedback will give you the best chance of success. Determining the timeline for MVP and MMP releases can be difficult but trust your judgment. And surround yourself with people who have done it before.

Has your business developed a product using a minimum viable product and minimum marketable product? Or do you combine them into one? Leave us a comment and share your experience.

For more information on Spotlight Software and our services, please contact us or visit our FacebookGoogle+LinkedIn, or Twitter profiles.

Friday Findings: Social Project Management

Status Updates

Social network-like Status Control

Posted By: Seth Weedin

Recently, a new approach to managing project teams has emerged combining traditional project management techniques with social network principles. Social networks allow project teams to communicate and collaborate on demand and in real-time, leading to a new management method called “Social Project Management”.

At Spotlight, we found the value of using social networks to keep our project teams communicating frequently during a project, especially since our entire company is virtual. But instead of using each social network individually, we integrated these social media principles right into our people and project manager app. Now development teams all over the world can stay in contact through the integrated social media features and project management techniques from their computer, mobile, or tablet device.

We aren’t the only ones jumping on the social project management trend. Thomas Kennedy, founder of is currently holding a business study on Elizabeth Harrin’s book Social Media for Project Managers. They go through the entire book in a study outline to help you take advantage of social media for project team collaboration.

In this week’s Friday Findings, we look at how social project management is being used for project teams to help them communicate better.

The Findings

  • This article looks at how social tools are used in project management. One major advantage? It cuts down on emails.
  • A look at social media’s place in social project management. A good reminder in this article not to forget about security when communicating across social mediums.
  • Integrating social media principles into project management can be quite a change for traditional project teams. Here are some tips for integrating social into your project management methods.
  • If your business is thinking about moving towards the social project management ideal, here are 10 considerations to think about when making the transition.
  • Social project management works best when a good balance is found between the social media tools and traditional project techniques. Here’s some keys to balancing the two and using social media to improve collaboration in “extended” project teams that comprise all stakeholders.
  • Here’s a great article from MindJet with a look at social task management to help conquer time, budge, and scope challenges.

As you can see, social project management is a trend that is gaining popularity. Spotlight integrates social principles into all aspects of our people and project manager app to help keep our software teams on the same page. If you are interested in seeing Spotlight PPM’s social integration live, join our webinar next Wednesday, May 22nd.

Has your business integrated any social media methods into project management? Let us know how it’s going!

For more information on Spotlight Software and our services, please contact us or visit our FacebookGoogle+LinkedIn, or Twitter profiles.

The Who, What, and Why of Project Goals

Project Goals DefinitionUser stories, also sometimes referred to as project goals, help stakeholders track major deliverables throughout the duration of a software development project.  The stories describe the desired user interaction with a specific feature of a software application. Building an eCommerce system would be an example of a user story that describes the process someone goes through to actually purchase an item or service.

We recently introduced project goals (or user stories) into Spotlight PPM for easy tracking of major software project deliverables. Clients, upper management, and outside stakeholders can use these goals to track certain parts of a project that directly involve them. For example, the CFO of your company may want to track the progress of the eCommerce system implementation mentioned above.

So exactly what does a project goal or user story entail? They commonly use this format: As a (who), I want (what), so that (why). Let’s take a look at each part of the equation in who, what, and why from various user and role perspectives.


There are several types of users that can make up the WHO portion of the user story equation. While end-users are the obvious WHO, others include project stakeholders and product owners.

Project stakeholders want an easy way to include new feature ideas on the product backlog. They usually don’t need to provide specific details of the story yet but just want a placeholder for further discussion. This gives the project team a heads up of new features coming down the pipe.

End users provide the basis for a user story in how they will interact with a new feature or improvement. Development teams that can gather this information from end users have a basis for the features that were originally outlined in the requirements analysis, making them easier to understand. The end user also provides data for consideration of new features that will make an application more user-friendly and robust.

The Project Manager and Product Owner both utilize user stories when creating the project backlog. The stories are much easier to prioritize without all the details of tasks getting in the way initially. The development team can then use a story to decide what tasks are needed to make it a reality.


Using the format above of “As a (Who), I want (What), so that (Why)”, the WHAT portion of user stories explain how users expect the software or system to behave. Using our example of an eCommerce system above, users will typically want the system to keep track of all the items added to the cart and check them out via a secure processing method at the end.

This portion of the user story equation typically outlines a feature or action the user wants to happen. Usually this will be a new behavior in the system, such as order tracking or integrating with PayPal for another payment method.


The WHY portion of user stories explain why a user, role, or system wants to be able to perform the desired interaction with the software. Going back to our eCommerce system example, a company would want the ability to cancel customer orders if requested, so the customer is satisfied and will potentially come back later for a repeat purchase. Keeping the customer satisfied to leave the door open for a purchase in the future is the WHY part of a user story.

Another aspect of the WHY portion are the reasons for product owners, project managers, and the development team to actually use user stories. For product owners and project managers, user stories make the backlog easier to manage. Since they are only an overview to describe what interaction is to take place between a user and the application, they are easier to organize and also let the development team know what’s lies ahead.

User stories also encourage communication and collaboration between different parts of the team to brainstorm what functionality is needed to implement the story. As the project team and stakeholders work together to achieve this, everyone gets in sync with each other to create a highly productive work environment.

Because user stories provide an overview of a user’s path through a new software application, it helps ensure that important requirements are not missed. Addressing the requirements in a group of user stories lays the groundwork for the development course, where detailed tasks can be added later. Trying to identify these detailed tasks immediately runs the risk of some requirements getting missed.


Quality user stories and project goals justify the reason for a new feature or improvement. They help project stakeholders keep track of the project’s progress and let development teams know what’s coming in the future. The stories can be added to the backlog almost immediately and serve as a placeholder for the future enhancements that satisfy the requirements. Think of it as the forest, with the trees being detailed tasks to implement the new story.

Project Goals in Spotlight use the typical format of having a product owner and all the specific tasks needed to create the user story feature as shown below. Oftentimes, we create new goals well ahead of time with no specific tasks yet for a placeholder as discussed previously.

Spotlight's User Stories and Project Goals

Is your software development department using user stories for new features? Leave us a comment with your experience.

For more information on Spotlight Software and our services, please contact us or visit our FacebookGoogle+LinkedIn, or Twitter profiles.

Friday Findings: Software Project Reports

Project managers have all heard those dreaded words coming from upper management: “Have a project report on my desk by tomorrow.” While they definitely aren’t the most enjoyable aspect of being in software project management, they are imperative.

To help you be better prepared the next time your boss comes by your desk and drops that phrase, here are 10 articles to help you create reports faster while maintaining quality.

The Findings

  • Creating weekly status reports for a software project keeps stakeholders and the project team on the same page. But don’t confuse it with a daily scrum report.
  • These tips on creating a project report from front to back will the management team informed and happy. Great take from a manager’s perspective.
  • This article from Tech Republic describes some great project reporting methods for Agile software projects. Specifically, four reports are used after every Scrum iteration.
  • Communicating the status of an Agile project report to upper management can be a challenge. This slideshare presentation helps you bridge the gap when giving status reports.
  • When your boss or project sponsor walks up to your desk and asks for a project report on the fly, make sure to have these 5 essentials ready to go.
  • Project reports can come in two different forms: from the PM to upper management and from the project team to the PM. Learn how to utilize both types of reports.
  • Another article from BrightHubPM showing you how to keep your project stakeholders informed without the traditional status report. Try keeping them engaged with a weekly newsletter.

Spotlight PPM automatically generates project status reports on demand. These reports include everything from a breakdown of sprints and tasks to billable hours by team member. Check out our webinar next Wednesday, May 15th to see how Spotlight can generate the project reports you need to keep upper management informed and pleased.

For more information on Spotlight Software and our services, please contact us or visit our FacebookGoogle+LinkedIn, or Twitter profiles.

Author Profile
Seth Weedin ( is the Director of Marketing at Spotlight Software.