How do you build product knowledge when new to the product?

🗄️ Archive
,
1

How do you build product knowledge when you are new to the product?

What’s the first thing you look for?

1 Like
2
  1. Ask an expert on the product for a demo
  2. Do exploratory testing with different heuristics
  3. Ask ‘why’ for different things (why is it done this way and not the other?)
  4. Ask different people to find out about how they use it, what they like/dislike about it
  5. Ask about the history of how the product was developed
1 Like
3

I always use a combination of making a mindmap of the product and then while creating the mindmap, note down any questions or ‘not so obvious’ bits I need to ask about. Then I can ask someone, or as usually happens, ask someone to ask someone else.

As a freelancer, most of the time I’m working on a new product - or a product that’s new to me - so have to build in some time learning the product, spotting any obvious flaws, omissions, possible errors etc, as well as working out the main product processes and flows.

3 Likes
4

Well there are two cases when a new employee want to learn product knowledge.

Case -1:

  1. Most of organization maintainining clear hand over process or documenting all important knowledge about product. A new person can learn through formal process by going through documents , material or artifacts.
  2. Approach leaders or Managers to request them to arrange sessions with experty.

Case 2:
Some of teams doesn’t have any documents related to product due to short deadlines on releases.
Well in this case, A person must put a lot of efforts to earn the knowledge.

  1. Go through code
  2. Go through all available documents
  3. Approach experts and ask them questions
  4. Involve in product discussions.
  5. Spend extra time to explore the product by yourself.
  6. List out all your questions/clarifications and track them status with experty that status is still on pending or open.
  7. Note down all important points about product and track them in a separate notes.
5 Likes
5

I’d look for some answers to questions like:

  • how long am I there for?
  • what time do I have available for learning?
  • what time do I have available for product knowledge learning?
  • at what depth do I afford to go in which parts of the product?
  • what am I hired for, as - is product knowledge relevant for that, to what degree?
  • what layer of the product is relevant to learn about in my context?
  • are there resources to learn from? documents, people, products internal to the company, external (internet, libraries, books, other products)
  • do I have access to the resources or are they secret, locked, non-available?
  • how much can I trust the product knowledge that I am stumbling upon? do I have to distrust most of it or ignore it as outdated?
  • what is the relevance of the product knowledge? how will I use it, when, in which context, for what purpose

Some good examples of specific tasks of learning product knowledge was already given above.
But context is key, as you don’t necessarily to the same thing in any place at any time.

3 Likes
6

I get involved in the testing as hands on experience is the best and it helps as a test manager/lead to understand risk.

I’m not afraid to asks questions even the muppet ones (well no question is silly)

1 Like
7

I have just started a new job within an organization who are creating a web version of their application that has been around for 20+years and it’s been tricky.

So far I have had countless demos, been allowed access to their support knowledges base, some exploratory testing with lots of bugs found already and using test cases/user guides already created.

The tricky part is that the company hasn’t a set testing process and a customer success manager has been testing the product so far, hence the number of bugs being found I guess. So my biggest challenge is learning a new product whilst trying to figure out the best testing process to implement to the company.

2 Likes
8
  • Read any existing documentation, both customer facing and for the engineering teams (and most likely find some differences between what it says it should do and what it actually does!)
  • Pair with someone who knows the product well - explore the product together. Try and get different perspectives - from a product/customer facing team and a developer for example
  • Try and find out any pain points. What major issues is the team facing just now with the product?
1 Like
9

I’ve been a tester on a product where the initial development team left.
A new team had to take the product over for some maintenance, refactoring, updates.
The testers which were still left in the company didn’t understand the product well enough or had nothing to say about it. The issues backlog was almost empty or non-existent.
The product was a freeware and had a low priority for the company.

There was nothing like documentation, someone that knows the product, team or pain points… about the product, except for the source code. Deadline 4-5 months to update it and create a stable version for the next 3-5 years: 1 dev(half-time), 1 tester(half-time), one overlooking PM/CTO(dedicating 1-2 hours/week);

11

Ouch. That doesn’t sound ideal! I suppose context is important and my answer wasn’t meant to be a one size fits all.

What did you do in that scenario? Look at the source code? Explore the product’s functionality by using it? How did you ensure the same thing wouldn’t happen to another team in a couple of years time?

12

I try to not get someone to demo the product to me, or watch anything more than a 5 minute demo. This let’s me keep myself distant from contaminating knowledge about UX flaws.

I then try to use the product with only the same kind of training/info a customer gets, in much the way we expect a customer/user to be able to do. I need to work carefully here though, because any mistakes can lead to actual equipment damage, or wasted time, if in doubt at any step, look for documentation. I thus make notes anywhere that I struggle and build out exploratory testing style as I go, being sure to keep to a path that takes in broad set of environments and use cases. The broader you go with environments (this is the point I ask for external inputs most) , the better I can understand the product quality.

I like to use notes taken during this time to help other new starters, and to drive UX improvements.

2 Likes
13

I was in a similar position a few years ago, except that the product the company produces was even more mature (35 years or so!).

I was fortunate in that I joined just at the point where the test team were setting out on what was an annual regression testing round. The idea was that once a year, the testing team spent one sprint on regression, to try to ensure that the previous year’s enhancements/bug fixes hadn’t broken anything. That’s become more targeted since, but at the time it was very useful in bringing me up to speed on the product.

1 Like
14

Hi All,
this is a very good question as in many ways we either are in this position or trained someone who just started in the company.
1- find the subject matter expert on the area you are testing.
2-find documentation if there is any. (mindmaps, diagrams, process maps,how to guide,test scripts,etc)
3-Start documenting if there is none or scarce.
4- Start doing exploratory testing.
5…Next thing you know you will be the subject matter expert =)

Happy testing!
Farah

3 Likes